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] ! c 
l HA A ad ENG aj É3 GTE 
u Egyedülálló lehetőség a felhasználóknak 


bárki saját személyes címlistát készíthet a letöltött adatok felhasználásával 


mp Speciális keresési opciókkal 


Több mint 90 000 cég, vállalkozás adatai az 


ország egész területéről, keresési lehetőségek: 


(Budapest, Győr, Miskolc, Pécs és Szeged) 


angol és magyar nyelven egyaránt. 


www.superpages.hu 





név, cím, telefonszám, tevékenység és kerület alapjár 


A keresett cég telephelye megtekinthető térképen is 


Minőségi ugrás: a Tablet PC 


Szerkesztőség 
Főszerkesztő: Fóti Marcell 
marcellfonetacademia.net 
Főszerkesztő-helyettes: Fülöp Miklós 
mickCnetacademia.net 

A szerkesztőség címe: 

1062 Budapest, Andrássy út 62. 
Tel.: 472-1214 
technetOnetacademia.net 
Nyilvános levelezési lista: 


tech.netOtechnetklub.hu 


Kiadja és terjeszti a 

NetAcademia Kft. 

Terjesztési, előfizetési információ: 
Tel.: 472-1214 
terjesztesgodnetacademia.net 
Megjelenik havonta, ára 1.344 Ft 


NetAcademia € Copyright 2002 
Minden jog fenntartva, beleértve 

(a részleteket illetően is) 

a sokszorosítás, a nyilvános előadás, 
fordítás jogát. A magazinban közölt 
cikkeket, képeket és illusztrációkat a 
kiadó engedélye nélkül közölni, 
reprodukálni tilos. 


Előfizethető megrendelőlevélben a 
szerkesztőségnél: 

1062 Budapest, Andrássy út 62. 
Fax.: 472-1215 
http://technet.netacademia.net/subs. 


Hirdetésfelvétel:Szívós Éva 
Tel.: 472-1214 
Fax.:472-1215 
info(Dnetacademia.net 
Grafikai tervezés, kivitelezés: 
Gregor László 

Nyomdai előkészítés: 
NetAcademia Kft. 


Nyomda: 

Hieron Kft. 

2120 Dunakeszi, Tamás A. u. 11/a 
Felelős vezető: Török Andrea 


ISSN 1586-5185 





Az elmúlt hetekben több vidéki városban is felbukkantam a Microsoft szokásos évi előadás- 
sorozatának szereplőjeként. Ha már ott voltam, nézőként is ,hasznossá tettem magam", vagyis 
odafigyelve végighallgattam a többi előadást. Az utolsó előadás, melyet az Egyik Nagy Pro- 
cesszorgyártó képviselői abszolváltak, különös érzéseket keltett bennem. Úgy éreztem, ez a 
nagy cég fél valamitől. Nem a konkurenciától. A recessziótól. De attól nagyon. És ebbéli félel- 
mükben nem átallottak hatalmasabbnál hatalmasabb lózungo- 
kat megereszteni a közönségnek, akik szerintem szintén kihal- 
lották azt, amit én. 

Van-e valaki ebben a szakmában, aki igazat adna annak az ér- 
velésnek, hogy a dolgozók termelékenységét növeli, ha 800 
MHz-es asztali gépeiket 1,6 GHz-esre cserélik? Jól hallották, a 
termelékenységük növekszik. Egy titkárnőé? Ettől? 


Mondok én a processzorgyártóknak valamit. Innen, Magyaror- 
szágról. A mennyiségi növekedés erőltetése helyett valami mi- 
nőségi ugrást kellene produkálni már. De megfizethető áron. Az 
árak miatt a 64 bites világ sajnos nincs elég közel hozzánk. 
Okosan hangzik, nemde? Egy nagy baj van csupán: a színpadon 
a Windows áll, az ő produkciójával találkozik a felhasználó. A 
processzor valahol a háttérben, a zsinórpadláson dolgozik, és rendezgeti a szálakát A háttérből 
kellene a nézőtérre kiható, a publikumot felkavaró dolgot produkálnia. Nehéz eset, nem mon- 
dom! Erre csak egy esélyt látok: ha előadás közben leengedik a függönyt ;). 





A színpadon azonban most is történik olyan minőségi vál- 
tozás, ami a zsinórpadlás legénységének is hasznára fog 


ta 
E f válni: jön a Tablet PC! 
ső S Aj Ezzel az eszközzel az informatika további helyekre hatol 
BZ be, és — hál"Istennek - megnövekedett processzorteljesít- 


ményt igényel. Amit egyszer Bill elgondolt, az úgy lesz. 

Information at your fingertip. Anytime, anywhere computing. Én úgy saccolom, a Tablet PC 

lendületes terjeszkedésbe fog kezdeni. Évek óta van ugyanis egy-két olyan terület, amely hiá- 

ba várta informatikai ellátottságát: 

s Az egyik ilyen terület a monitoron történő olvasás. Ma hiába szeretném a tech.net magazint 
webre vinni, ez egyenlő lenne az olvasótábor megszűnésével, mert négyoldalas cikkeink leg- 
alább 16 képernyőn terjeszkedve olvasási rémálommá válnak. Valódi híveink bizonyára ki- 
nyomtatnák a cikkeket. A Tablet PC ClearType technológiája segítségével talán végre képe- 
sek leszünk monitoron elolvasni a dokumentumokat. 

e Szintén ellátatlan terület a webes mikrofizetés. Webes tartalomért a mai napig nem lehet 
kérni egy vasat sem. Évek óta várják a tartalom-előállítók, hogy a neten át is érvényesíthes- 
sék pénzkereseti igényüket. Most majd kapunk Digital Rights Managementet, talán még di- 
gitális pénzt is (lásd ehavi számunk idevágó cikkét a jogi rovatban). 

. Jegyzetelésre még mindig legjobb a papír és ceruza. Ezt kellene leutánozni. A Tablet PC meg- 
teszi. 

Persze van, ami még most sem lehet a mienk. Mi a helyzet a magyar beszéd és a magyar kéz- 

írás felismerésével? Erre azt hiszem egy keveset várnunk kell még. 

A hardvergyártók mindenesetre megnyugodhatnak: pár év múlva már csak a minimum 10 

GHz-es processzorok lesznek eladhatók. S gépenként minimum négy kell majd belőlük. 


Fóti Marcell 
miarcelkonésesdemiai net 
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Farkasokkal táncoló XI. 
Cluster a gyakorlatban  4.oldal 


A fürtszolgáltatással ismerkedők számára kezdetben nagyon kellemes, hogy a fürt ,,min- 
dent elintéz". Főleg, ha esetleg a rendszert készen kaptuk, vagyis a szolgáltatások már 
működtek, amikor az eszköz a kezünkben került. Aztán jön az első saját telepítés, az 
első erőforráshiba, és a rendszergazdának meg kell tanulnia alámerülni a fürtszolgálta- 
tás mélységeibe. 






Active Directory: FSMO szerepek 8. oldal 

Az előző részben végigvettük a tartománytelepítés lépéseit. Most megvizsgáljuk, milyen 
kiszolgálószerepek születtek. A hagyományos tartományvezérlői szerepeken túl ugyan- 
is lett PDC Emulator, Schema Master, Domain Naming Master, RID Master és 
Infrastructure Master szerepkör is. Ezeket összefoglaló néven FSMO (Floating Single 
Master Operations) szerepeknek nevezzük. 
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Sémamódosítás plusz adatmódosítás — 10. oldal 


Az Active Directory nemcsak , gyári" adatok tárolására képes, hanem a séma bővítésével tet- 
szőleges további attribútumok adhatók a meglévő objektumokhoz. Felvehető a címtárba pél- 
dául a felhasználók személyi száma, a számítógépek gyártási száma, a felhasználói csoportok 
gazdasági adatai stb. 








VPN - Virtuális magánhálózatok 
2. rész, Az L2TP protokoll 14. oldal 





Az előző részben körüljártuk a VPN hálózatok , lényegét", Windows 2000 kiszol- ÉV. ! SEReTmBr Bi § 9 
gálónkon varázsoltunk egy VPN kiszolgálót és csatlakoztunk is hozzá — egyelőre málösés tandó vegy ázendő a 
csak egy munkaállomással, PPTP kapcsolaton keresztül. Ma terítékre kerül az új ök imternetkapcsolat kapcsolat plsk 
protokoll, az L2TP is. 

c) Digital Money 19. oldal 

G Az elektronikus kereskedelemről és az elektronikus aláírásról szóló törvények megteremtették Magyar- 

országon is a jogszabályi hátterét annak, hogy az Interneten keresztül áruk, illetőleg szolgáltatások cse- 
1 réljenek egymással gazdát, vagyis végre meginduljon az elektronikus kereskedelem. 
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Nyilvános mappák 20. oldal 





NT Uset:BUILTI. 


Az Exchange 2000-ben a nyilvános mappák területén fontos változtatások 
xy történtek. Az Exchange és az Active Directory összefonódásaként a jogo- 
cgi a Ésszel sultságok kiosztása, és használata módosult. Ahogy az adatok elérése is 
sokféle módon történhet, a jogosultságok állítása is bonyolultabb. Miután 








10 no: 80040102 
Esetegos SAtEKÉKIETBdEt] megismerkedtünk kicsit a nyilvános mappákkal, belevetjük magunkat a 
járzkeai jogosultságok dzsungelébe. 
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XMLgessünk 16. ESETEI 
] Be  Edt View  Favorites  Iools Help KH 
SOL XML 3.0-I.rész 24. oldal KRKENÉ toviltocsettttlezásíste sza. KÍETENI 
Az SOL Server 2000 számos beépített XML- szolgáltatással rendelkezik, viszont a v.2) DOOOJOJO:D DO OwJO 007ROD(DOZB 
4 rálanézeőt (nél é é § ógiál SOKOJOONOOT"OCOSOYI YO$OOVAO 
termék megjelenése óta több mint három év telt el, és az XML- technológiák pont HELÖNEHTÉTETTÉ TET Si 





az utóbbi időben indultak szédületes fejlődésnek. Az SOL Server emiatt újabb és 
újabb XML- szolgáltatásokat kapott, melyeket külön csomagban lehet letölteni. Ez 
az SOLXML programcsomag. 





.NET Akadémia VIII. 


Többszálú és aszinkron programozás 28. oldal 

A többszálú programozás az egyik legtipikusabb felhasználói módú programozási terület, 
ahová csak a legelszántabb C-t--- programozók merészkedtek el. Windows API használa- 
tával időnként tényleg nehéz helyzetben találjuk magunkat, de a Common Language 
Runtime nagyon leegyszerűsíti az életünket, ha menedzselt környezetben kell többszálú 
programokat fejleszteni. 





Az UML — 7T1.rész 34. oldal a e a 
A modellezés témát folytatva, pontosabban részletezve UML sorozatom első részé- Gomeotant Ve " Dásójítadtvtási 
ben a módszer kialakulásának körülményeit szeretném bemutatni, illetve néhány kej. 
olyan alapfogalmat, amelyek megértése elengedhetetlen a későbbiek megértésé- E 





hez. 
Process view 


j 7 Design view 
esel, ( 


"e, 


OfficeXP Resource 39. oldal 
Akik kicsit jobban belemélyedtek az Office lelkivilágába, azok már jól ismerik az Office Resource Kit 
eszközök nyújtotta lehetőségeket. Most egy újabb verzióját tölthetjük le ennek a csomagnak. 






Orregér — 40. oldal 


Azok, akik hosszú órákat töltenek a számítógép előtt, tudják mit jelent egy nem éppen kifogástalanul . 
működő egér. A mikrokapcsolók — inkább előbb, mint utóbb — már csak eredménytelenül kattognak, 
a golyóra minden szösz ráragad, a görgőkre kiválóan tekeredik fel a leghosszabb hajszál, és az egéralá- 
tét vagy a kábel éppúgy véget ér, mint a türelmünk. 


(110001 
001010 
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E Farkasokkal táncoló 


(XI. rész) - Cluster a gyakorlatban 


Farkasokkal táncoló (XI. rész) - Cluster a gyakorlatban / 


A fürtszolgáltatással ismerkedők számára kezdetben nagyon kellemes, hogy a fürt ,,min- 
dent elintéz". Főleg, ha esetleg a rendszert készen kaptuk, vagyis a szolgáltatások már működtek, amikor 
az eszköz a kezünkben került. Aztán jön az első saját telepítés, az első erőforráshiba, és a rendszergaz- 
dának meg kell tanulnia alámerülni a fürtszolgáltatás mélységeibe. 


Ezt a mélységet a cluster.log jelenti. Érteni a naplót annyit tesz, 
tudni, mi történik a háttérben. A háttér pedig feltárja a hibá- 
kat, amelyeket kergetünk hét határon át. Ez alkalommal a fürt 
belső eseménynaplóját elemezzük példákon, helyzeteken ke- 
resztül. 


Munkamódszer 

A cluster.log elemzésekor konkrét szituációkon keresztül 
vizsgáljuk meg, hogy mi kerül a naplókba. Terjedelmi okok- 
ból nem tudjuk elemezni a bejegyzéseket sorról sorra, ezért 
a már megismert, ismétlődő, és könnyen értelmezhető ese- 
ményeket az írás közben csak említem, de nem idézem. A 
cikk végén található hivatkozásokról letölthetők a teljes nap- 
lók, hogy akik szeretnék még alaposabban boncolgatni a 
helyzet szülte bejegyzéseket, azok megtehessék. (Bevallom, 
e nélkül eléggé bonyodalmas olvasmány lesz a cikk.) A fürt 
mindkét állomásának naplóit érdemes végigböngészni, így 
láthatóvá válik, miként érzékeli ugyanazt az eseményt az 
egyik, illetve a másik node. A felesleges információk elkerü- 
lése érdekében kihagyom a naplóbejegyzések elején találha- 
tó processz- és szálazonosítókat, valamint az időbélyeget is, 
hacsak nincs különös jelentőségük. A naplók letölthető válto- 
zatában ezek természetesen jelen vannak. Végezetül feltéte- 
lezem, hogy az előző hónapban tisztázott fogalmakat az OI- 
vasó elsajátította. 


Egy állomás indulása 
A napló egy olyan helyzetben készült, amikor a két állomásból 
álló fürt első kiszolgálója indult el, a másik még áll. A teljes nap- 
ló az [1] címről tölthető le. 
Az első két sort már ismerjük, a naplóbejegyzés a fürtszolgál- 
tatás indulását jelzi. Ezután az esemény-feldolgozó kompo- 
nens [EPJ indul, hogy rögtön elkezdhesse a bejegyzések rögzí- 
tését. 

(EP] Initialization... 

[DM]: Initialization 


Az esemény-feldolgozót az adatbáziskezelő szál követi. Tulaj- 
donképpen minden szálat inicializálnia kell a fürtszolgáltatás- 
nak, a naplóból láthatjuk, hogy ezt meg is teszi. 


IDM]: Loading cluster database from 
C:NWINNTYVCluster(CLUSDB 

[DM] DmpStartFlusher: Entry 

[DM] DmpStartFlusher: thread created 


Az adatbáziskezelő első dolga, hogy beolvassa az adatbázist. 
Az előző részben már tárgyaltuk a szolgáltatás indulását, és 
tudjuk, hogy a fürt ebben az állapotban még nem tudja, hol 


van a Ouorum erőforrás, így a 9osystemroot9yelcluster mappá- 
ban található clusdb állományt olvassa be, amely a guo- 
rumerőforráson található adatbázis egy másolata. Nem biz- 
tos, hogy tökéletes másolat, arra azonban elegendő, hogy a 
szolgáltatás információkat szerezzen a guorum hollétéről és 
az erőforrásokról. (Igazság szerint még ezek az információk is 
elavultak, de létezik egy mechanizmus, amely az ilyen 
komplikációkat kiküszöböli.) 

A többszálúság előnyeit kihasználva azonnal indul a többi 
szál is, nem várva meg más szálak munkájának befejezését. 
Előbb a node manager, aztán a failover manager, az API és a 
log manager komponensek inicializálódnak. A node manag- 
er azonnal munkához lát, és a beolvasott adatbázisból azo- 
nosítja az állomást és annak számát. 


INM] Local node name - MALSERVER3. 
INM] Local node ID - 1. 
INM] Creating object for node 1 (MALSERVER3) 


Egy külön komponenshez nem köthető szál megállapítja, hogy 
milyen fiókkal indult a szolgáltatás, majd az adatbázisból kiol- 
vasott fürtnevet felhasználva megpróbál csatlakozni a másik ál- 
lomáshoz. A szolgáltatás azt feltételezi, hogy a másik állomás 
— és így a fürt maga — működik. 


[CS] Service Domain Account - MALVclustuser 
ICS] Initializing RPC server. 
[INIT] Attempting to join cluster MAL-CORPSERV3 


A napló elemzése közben többször is feltűnik majd, hogy a 
szoftver minden része ,ideges" és ,siet", vagyis a feladatát 
minden lehetséges módon és minél előbb szeretné elvégezni. 
A következő sorokból látszik, hogy a másik állomáshoz való 
csatlakozást a fürtszolgáltatás a létező összes hálózati csatoló 
nevével és IP címével megpróbálja. 


(INIT] Attempting to join cluster MAL-CORPSERV3 
[JOIN] Spawning thread to connect to sponsor 
192.168.112.1 

[JOIN] Asking 192.168.112.1 to sponsor us. 
[JOIN] Spawning thread to connect to sponsor 
10.0.0.21 

[JOIN] Spawning thread to connect to sponsor 
MALSERVER4 

[JOIN] Asking 10.0.0.21 to sponsor us. 

[JOIN] Asking MALSERVER4A to sponsor us. 


Érdemes megfigyelni a rendszer állapotváltozásait. Előbb INIT 
állapotba kerül a szolgáltatás, amit a JOIN követ. Ez utóbbi 
mindaddig fennáll, amíg a csatlakozási folyamat sikeresen 
vagy sikertelenül be nem fejeződik. 

A leírt szituációból tudjuk, hogy ezúttal a csatlakozás nem si- 
kerülhet, a következő bejegyzés tehát nem váratlan: 
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2002/07/19-19:38:35.654 [JOIN] Sponsor 10.0.0.21 
is not available (JoinVersion), status-1753 


A sikertelenség oka a státuskódban rejlik. A korábban ismerte- 
tett módszerrel pontosabb információhoz juthatunk. 


cC:Nosnet helpmsg 1753 
There are no more endpoints available from the 
endpoint mapper. 


Ez az utasítás még sokszor a segítségünkre lesz, tartsuk szára- 
zon a parancssorunkat. 

A próbálkozás egy idő után abbamarad. Figyeljük meg, hogy 
az utolsó próba épp harminc másodpercig tart. 


19:38:36.654 [JOIN] Waiting for all connect 
threads to terminate. 

19:39:08.669 [JOIN] Sponsor 10.0.0.26 is not 
available (JoinVersion), status-1722. 
19:39:08.669 [JOIN] JoinVersion data for sponsor 
10.0.0.26 is invalid, status 1722. 
19:39:08.669 [JOIN] All connect threads have 
terminated. 

19:39:08.669 [JOIN] Unable to connect to any 
sponsor node. 

19:39:08.669 [INIT] Failed to join cluster, 
status 53 

19:39:08.669 [INIT] Attempting to form cluster 
MAL-CORPSERV3 


Az 53-as kód azt jelzi, hogy a hálózaton keresztül a másik ál- 
lomás nem elérhető. A szolgáltatás visszakerül INIT állapotba, 
és megpróbál egyedül fürtszolgáltatást kialakítani. Vessünk egy 
pillantást az időpontra: 19:39:08.669! 

A napló végén láthatjuk majd, hogy az üzemszerű működés 
eléréséhez csupán 12 másodpercre lesz szükség. Az állomás a 
korábban beolvasott adatbázis alapján felépíti a fürtöt, megke- 
resi a guorum logot, és a chekpointállományokat, azok segít- 
ségével pedig helyreállítja a fürt legutolsó állapotát. Ezt a folya- 
matot követjük végig. 


A fürt kialakítása a helyi adatbázissal 

Az első lépés, amelyet meg kell tennie a clusternek, az erőfor- 
rás-ellenőr (resrcmon.exe) indítása. Az előző cikkből tudjuk, 
hogy a fürtszolgáltatás az ellenőr segítségével tartja a kapcso- 
latot az erőforrásokkal. Mivel a végső feladat az erőforrások el- 
indítása, a műveletet meg kell előznie az ellenőr üzembehe- 
lyezésének. 

A helyi adatbázis — ahogy az már korábban kiderült — nem 
más, mint egy ág a regisztrációs adatbázisban. A következő be- 
jegyzések ezt jól mutatják. A failover manager [FMI sorra az 
erőforrásokat reprezentáló regisztrációs értékeket olvas be, 
majd inicializálja azokat. 


19:39:08.669 (API] Online read only 

IRM] Main: Initializing. 

[FM] Creating group 9b26a6cb-a791- 
4807-9c17-bfc83050cd13 

[FM] Initializing group 9b26a6cb-a791-4807-9c17- 
bfc83050cd13 from the registry. 

[FM] Name for Group 9b26a6cb-a791-4807-9c17- 
bfc83050cd13 is "MAL-CORPSERV3!". 

[FM] Group 9b26a6cb-a791-4807-9c17-bfc83050cd13 
preferred owner 1. 

[FM] Group 9b26a6cb-a791-4807-9c17-bfc83050cd13 
contains Resource 54235£9f-3789-442a-98£1- 
e22bd2£f73b66. 

[FM] Creating resource 54235£9f-3789-442a-98£1- 
e22bd2f73b66 

[FM] Initializing resource 54235£9f-3789-442a- 
98£1-e22bd2f73b66 from the registry. 

[FM] Name for Resource 54235£9f-3789-442a-98f1- 
e22bd2f73b66 is "Cluster IP Address". 

FM] FmpAddPossibleEntry: adding node 1 





as possible host for resource 
54235£9f-3789-442a-98f1-e22bd2f73b66. 
IFM] FmpOueryResTypelnfo: Calling 
FmpAddPossibleNodeToList for restype 
IP Address 

IFM] FmpAddPossibleNodeTOoList: adding 
node 1 to resource type!s possible 
node list 

[FM] FmpAddPossibleNodeTOoList:Warning, 
node 2 not found 

IFM] All dependencies for resource 
54235£9f-3789-442a-98f1-e22bd2f73b66 
created. 


A koreográfia felismerhető: 
1. Az FM létrehozza a memóriában az erőforráscsoportot. 
2. Beolvassa a csoporthoz tartozó regisztrációs értékeket. 
. Megállapítja az erőforráscsoport nevét. 
. Meghatározza, hogy a csoportot melyik állomás fogadhatja. 
. Megvizsgálja, hogy a csoport milyen erőforrásokat tartal- 
maz, és sorra veszi azokat is. 
a. Létrehozza az erőforrást a memóriában. 
b. Beolvassa a regisztrációs értékeket. 
c. Megállapítja az erőforrás nevét. 
d. Meghatározza a lehetséges állomásokat, amelyek birto- 
kolhatják az erőforrást. 
e. Meghatározza az erőforrás függőségeit. 
f. Megnyit minden erőforrást, amelytől az aktuális erőfor- 
rás függ, vagy ellenőrzi, hogy már megnyitotta-e azokat. 


WU A w 


A látottak alapján néhány fontos felismerést tehetünk. A fürt 
minden egyes erőforrást egy egyedi azonosítóval jelöl, egy 
meglehetősen , ronda" jelsorral, mint például 9b26a6cb- 
a791-4807-9c17-bfc83050cd13. Ezt a jelet GUID-nak hív- 
ják, ami a ,globális, egyedi azonosító kód" angol rövidítése. 
A GUID-ok meglehetősen nehézkessé teszik a napló olvasá- 
sát, mivel hosszúak és nehezen azonosíthatók. Segítségünkre 
lehet, ha a regedit (regedt32) program segítségével előre fel- 
jegyezzük az erőforrások nevét és azonosítóját. Ha a fürtnap- 
ló másolatával dolgozunk, érdemes írni egy rövid scriptet, 
amely sorra kicseréli a GUID-okat az erőforrások neveivel. 


État] 


rezes 


zjnve 





Id A regedít exe segíthet az erőforrások azonosításában 





Az erőforrások beolvasása mindaddig tart, amíg az FM meg 
nem találja a guorumot. 


19:39:08.778 [FMX] Found the guúorum resource 
£21ba2a4-62dd-4883-bf69-aa6c69f96320 - 

Az FMX a failover manager tranzakciós részét jelöli. 

Miután az erőforrás-kiértékelés befejeződött, az FM megkezdi 

a guorum ,birtokba vételét". Az erőforrásellenőr felveszi a 

guorumot a felügyelt erőforrások listájába. Az FmpRm pontos 

feloldására nem találtam hiteles információt, de könnyű azt 
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feltételezni, hogy a ,Failover Manager 
process Resource Monitor" helyett használ- 
ja a fürt. 


19:39:08.778 [FM] 

FmpRmCreateResource: creating 

resource f21ba2a4-62dd-4883-bf69- 

aa6c69f96320 in shared resource monitor 
19:39:08.857 Physical Disk: PnP widow created 
successfully. z 

[FM] FmpRmCreateResource: created resource 
£21ba2a4-62dd-4883-bf69-aa6c69f£96320, resid 651760 
IMM] MmSetOuorumOowner(1,1), old owner 0. 


A következő bejegyzés azért fontos, mert ez az első, amely 
nem a fürtkomponenstől, hanem az erőforrás-ellenőrtől szár- 
mazik: a Windows 2000 felkészül egy lemez fogadására. 

A sorban olvasható resid tulajdonképpen egy mutató az erő- 
forrás-ellenőr processzben. Az RM-en kívüli világban a resid 
nem más, mint hivatkozás egy konkrét erőforrásobjektumra. 
Végezetül a membership manager beállítja, hogy a guorum- 
nak melyik állomás lesz a tulajdonosa. Persze ezt egyelőre 
még csak a memóriában található adatbázisváltozatban teheti 
meg, hiszen a guorumhoz még nem nyúlt hozzá a fürt. 

A következő sorok egy tesztről tudósítanak, amelyet az RM vé- 
gez el, és célja a lemez írhatóságának és olvashatóságának el- 
lenőrzése. A teszt sikere után az ellenőr kiadja a lefoglalási 
(reserve) parancsot, az FM pedig bejegyzi, hogy sikeresen 
megszerezte az erőforrást. 


Physical Disk cDisk O:2: [DiskArbJ]Arbitrate 
returned status 0. 

Physical Disk cDisk O:2: [DiskArb] ttrikitiktitk 
IO. PENDING tikkttkkk 

[FM] FmGetOuorumResource successful 


Az ellenőr újabb sorai tanúsítják, hogy a lemezt sikerült műkö- 
dő (online) állapotba állítani. Figyelem! Ez még csak a lemez- 
re vonatkozik, nem a lemezt reprezentáló erőforrásra! A kü- 
lönbség mindjárt kiderül. 

A most következő pár sorral gyakran lehet találkozni a 
Cluster.log elemzése közben. A művelet azt jelzi, hogy a 
Global Updated Manager (GUM) változtat a fürtadatbázis 
tartalmán. Az első ilyen tranzakció a naplóban így néz ki: 


[GUM] GumSendupdate: Locker waiting type 0 context 8 
[GUM] Thread 0x7e8 UpdateLock wait on Type 0 
[GUM] DoLockingUpdate successful, lock granted to 1 
[GUM] GumSendupdate: Locker dispatching seg 
35714364 type 0 context 8 

[(GUM] GumpDoUnlockingupdate releasing lock ownership 
Physical Disk cDisk O:2: [DiskaArb] 
DisksOpenResourceFileHandle: Attach successful. 
IGUM] GumSendupdate: completed update seg 
35714364 type 0 context 8 

IFM] FmpPropagateResourceState: resource 
£21ba2a4-62dd-4883-b£f69-aa6c69f96320 pending event. 
[FM] FmpRmOnlineResource: Resource f21lba2a4- 
62dd-4883-bf69-aa6c69f96320 pending 

Physical Disk -Disk O:5: [DiskArb] 
DisksOpenResourceFileHandle: CreateFile successful. 
(IFM] FmpRmOnlineResource: Returning. Resource 
f£21ba2a4-62dd-4883-bf69-aa6c69f£96320, state 

129, status 997. 


A sikeres értelmezéshez ismerni kell a GUM frissítési műve- 
leteinek három típusát, valamint a kontextus kódok jelenté- 
sét. A táblázat a frissítési típusokat azonosítja. 


GUM typeO GumuUpdateFailoverManager 
GUM type1 GumuUpdateRegistry 
GUM type2 GumuUpdateMembership 


A kontextusszám értéke a frissítés típusától függ. Esetünkben a 
8 erőforrásállapot-változást (ResourcesState) jelent. A [2] hely- 
ről letölthető egy táblázat, amely a típusokat, a kontextus-szá- 
mok jelentését és a később tárgyalandó állapotkódokat is tar- 
talmazza. 

A fürtszolgáltatásban kialakítottak egy mechanizmust, amely 
megakadályozza, hogy egy időben több szál végezzen mó- 
dosítást az adatbázis adatain. A GUM kiad egy zárolási kérel- 
met, hogy a változtatást elvégezhesse, (GumSendUpdate: 
Locker waiting) megadva azt is, hogy milyen típusú adatmó- 
dosítás várható (type 0 context 8). Azt az állomást, amely a 
módosítást végzi, zárolónak (locker) nevezik. A sikeres záro- 
lásról bejegyzés készül (DoLockingUpdate successful, lock 
granted to 1). Ezt követően végzi el a GUM a tényleges írást, 
amelyet egy folyton növekvő tranzakciós számmal jelöl meg 
(GumSenduUpdate: Locker dispatching seg 35714364 type 0 
context 8), végül feloldja a zárolást (/GUMJ GumpDoUn- 
lockingUpdate releasing lock ownership). Az FM értesíti a 
többi állomást az állapotváltozásról (jelen esetben ennek 
nincs értelme, hiszen nincs másik állomás). A többi bejegy- 
zés érthető, egyedül a ,state 129, status 997" kódokat kell 
feloldani, amit szintén az előbbi Excel táblázattal tehetünk 
meg. A 129 annyit tesz ClusterResourceOnlinePending, 
vagyis az erőforrás épp indul, a státus pedig a net helpmsg 
parancs segítségével lesz érthető: ,Overlapped I/O opera- 
tion is in progress". Most már érthető, hogy mi a különbség 
a tényleges erőforrás és a hozzá tartozó bejegyzés között. 
Miközben az ellenőr szerint a lemez már működik, addig a 
fürtadminisztrátor programban az erőforrás még csak indul! 
A következő lépés a partícióhoz tartozó jelölés (O:) egysé- 
gességének ellenőrzése: 


Physical Disk cDisk O:5: Mountie[0]: 1, let-?, 
start-7E00, 1len-1EE28000. 

Physical Disk cDisk O:2: Online 

Physical Disk cDisk O:2: MountieVerify: Registry- 
SystemNDISK.GetInfo returned 0 [0:0]. 

Physical Disk cDisk O::: MountieVerify: ClusReg- 
DiskInfo selected. 

Physical Disk cDisk O:2: MountieVerify: 
DriveLetters mask is now 00010000. 

Physical Disk cDisk O:23: MountieVerify: Update 
needed for 08. 

Physical Disk cDisk O:2: FtInfo Set: Update 
successful. 

Physical Disk cDisk O:5: MountieUpdate: Update 
needed for 00. 


A hatodik sor jelzi, hogy a HELMISYSTEMWIisk bejegyzés nem 
friss. (, Update needed for 08". Sajnos, az esetleges további 
kódszámokról nincs információ. Itt valószínűleg arról van szó, 
hogy a lemez becsatolása után a regisztrációs adatbázist a 
Windows 2000 még nem frissítette.) A változtatást az erőfor- 
rás-ellenőr elvégzi, hogy aztán már azt írhassa ki , Update 
needed for 007. Újabb lemezellenőrzéseket végez az ellenőr, 
végül jelenti a fürtszolgáltatásnak, hogy az erőforrás állapota 
,Működőr"-re (online) állítható. 


IRM] RmpSetResourceStatus, Posting state 2 
notification for resource cDisk O:5 


Egy újabb érdekességre figyelhetünk fel. Ahelyett, hogy a 
GUM módosítaná az erőforrás állapotát , indul"-ról ,műkö- 
dő"-re, valami más kezdődik. A fürtadminisztrátorban még 
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nem történt állapotváltozás. A helyi adatbázis feladata lassan 
véget ér. Mindent előkészített a valódi guorum beolvasására. 
Ez az a hiányzó művelet, ami a GUM munkáját késlelteti. 


A valódi guorum betöltése 


[FM] NotifyCallBackRoutine: engueuing event 

IFM] FmpCreateResStateChangeHandler: Entry 

[FM] FmpCreateResStateChangeHandler: Exit, status 0 
[FM] FmpHandleResStateChangeProc: Entry... 

[DM] DmpOuoObDjNotifyCb: Ouorum resource is online 
[DM] DmpOuoObDbjNotifyCb: Own guorum resource, try 
open the guorum log 

[DM] DmpOuoODjNotifíyCb: the name of the guorum 
file is O:XMSCSVguolog.10g 

[ILM] LogCreate : Entry FileName-0:NMMSCSYVguolog.10g 
MaxFileSize-0x00010000 

ILM] LogpCreate : Entry 

[LM] LogpMountLog : Entry 

pLog-0x00098498 

[LM] LogpMountLog::Ouorumlog Fil 

e size-0x00008000 

ILM] LogpMountLog::reading 1024 

bytes at offset 0x00000400 

[LM] LogpMountLog::checking LSN 

0x00000408 


A guorumot a DM és az LM együttes munkával nyitja meg. 
Sajnos, a naplónak ez a szakasza nem pontosan dokumen- 
tált, a folyamat csak hozzávetőlegesen követhető. Nem is- 
mert az , Entry pLog—0x00098498" jelentése, sem az, hogy 
miért épp 1024 bájtonként történik a beolvasás, mit rejt az 
LSN rövidítés (logical seguence number?). Az alábbi pár sor 
is teljes rejtély: 


[LM] AddTimerActivity:: hTimer - 0x00000358 
pfnTimerCb-0x0107fb50 dwInterval(in 

msec) -120000 

[LM] AddTimerActivity:: Interval(high)-OxfFfrrffrf 
Interval(1ow) -0xb8797400 

[LM] AddrTimerActivity:: returns 0x00000000 


Mindeközben egyéb - szintén nem ismert folyamatok is zajla- 
nak. A 0x768 szál a sorok közt elszórva a következő bejegyzé- 
seket írta: 


00000768: [LM] :ReSyncTimerHandles Entry. 
00000768: [LM] :ReSyncTimerHandles Exit 
gdwNumHandles-2 

00000768: [LM] :ReSyncTimerHandles Entry. 
00000768: [LM] :ReSyncTimerHandles Exit 
gdwNumHandles-3 


A gdwNumHandles egy változó, akárcsak a gdwOuoBlocking- 
Resources, de a szerepe, ellentétben az utóbbival, egyelőre 
nem dokumentált. A sok ismeretlen jelentésű sor között van 
néhány, amely fontos a számunkra: 


[FM] HandleResourceTransition: Resource Name - 
f21ba2a4-62dd-4883-b£69-aa6c69£96320 old 
state-129 new state-2 


A GUID, az állapot- és a státuskódok megfejtése után látható, 
hogy a , Disk O:" erőforrás ,indul" állapota , működik"-re vál- 
tott. Ezt egy adatbázis frissítésnek kell követnie, ami pár sorral 
lejjebb be is következik. Egy másik fontos bejegyzés az alábbi: 


0000096c.000007e€8::2002/07/19-19:39:09.185 [DM] 
DmpChkOuoTombStone - Entry 


0000096c.000007e8: :2002/07/19-19:39:09.185 [DM] 
DmpChkOuoTombStone: Exit, return 

ing 0x00000000 

[FM] FmFormNewClusterPhasel, Entry. 

Ouorum guorum will be deleted 


Arról értesít minket a napló, hogy nem talált , guorum sírkö- 


vet". Előfordulhatott volna ugyanis, hogy mi- 
közben az épp most induló állomás állt, a 
másik állomás megváltoztatta a guorum he- 
lyét. Ekkor a mi állomásunk csak a hűlt he- 
lyét, vagyis egy , sírkőállományt" talált volna. 
Mivel azonban a sírkő nem mutat a guorum 
új helyére, az állomásunk nem tudta volna betölteni azt. Eb- 
ből az következik, hogy az állomás nem lett volna képes 
egyedül fürtszolgáltatást nyújtani, csupán csatlakozhatott 
volna egy másik, már működő node-hoz. A sírkő megléte 
esetén a szolgáltatásunknak haladéktalanul le kellett volna 
állnia. A bejegyzés szerint azonban ez nem következett be. 


[DM] DmpApplyChanges: The current registry 
seguence number 35714363 

ILM] LogGetLastChkPoint:: Entry 

[LM] LogGetLastChkPoint: ChkPt File 
O:MSCSVChkF432.tmp ChkPtSeg-35714098 
ChkPtLsn-0x00000708 Checksum-176054 

[LM] LogGetLastChkPoint exit, returning 
0x00000000 

IDM] DmpLogFindStartLsn: LogGetLastChkPt rets, 
Sedgtt-35714098 ChkPtLsn-Ox00000708 

IDM] DmpLogFindStartLsn: ChkPt not applied, 
search for next seg 

[LM] : LogScan: :Entry Lsn-0x00000708 ScanForward-1 
cCallbackRoutine-0x0106c056 


[LM] : LogScan: : Calling the scancb for 
Lsn-0x000010€e0 Trid-35714231 RecordSize-216 
[LM] : LogScan::Exit - Returning 0x00000000 

IDM] DmpLogFindStartLsn: LSN-0X00000000, returning 
0x00000000 

IDM] DmpApplyChanges: Exit, returning 0x00000000 
(IFM] FmFormNewClusterPhasel, Entry. Ouorum guorum 
will be deleted 


A napló szerint az LA megkeresi az utolsó checkpoint állo- 
mányt, majd egy rutin segítségével ellenőrzi, hogy az adott 
tranzakciók bekerültek-e az adatbázisba. A bejegyzés kicsit 
csalóka, az állományt ténylegesen nem kell még egyszer alkal- 
mazni, mert különben olyasmit is látnunk kellene, hogy , IDMI 
DmpLogFindStartLsn: chkpt uploaded from guorum log". 

Az utolsó sor arról tájékoztat, hogy egy új fürtszolgáltatás kiala- 
kításának első fázisa úgy kezdődik, hogy a guroumot rögtön 
töröljük. A magyarázatot azonban már csak a következő szám- 
ban adjuk meg... 


Lepenye Tamás, MCSE 2000 
lepenyetOmal.hu 





A cikkben szereplő 
[11 Eseménynapló 
http://technet.netacademia.net/download/cluster/nodestart.log . 

[2] Excel tábla 
http://technet.netacademia.net/download/cluster/farkasokkal XI.xls 
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Active Directory: 
FSMO szerepek 


Az előző részben végigvettük a tartománytelepítés lépéseit. Most megvizsgáljuk, milyen kiszolgálószere- 
pek születtek. A hagyományos tartományvezérlői szerepeken túl ugyanis lett PDC Emulator, Schema 
Master, Domain Naming Master, RID Master és Infrastructure Master szerepkör is. Ezeket összefoglaló 
néven FSMO (Floating Single Master Operations) szerepeknek nevezzük. 


A többforrású (multimaster) replikáció 

Az Active Directory mindegyik tartományvezérlője alkal- 

mas arra, hogy ott felhasználókat hozzunk létre. Úgy gon- 

dolhatják, ez nem nagy csoda, de valójában mégis az. 

Gondoljunk csak bele: két távoli gépen egymástól függet- 

lenül változik valami a címtárban (itt létrejön egy objek- 

tum, amott átköltözik vagy törlődik egy másik), majd a rep- 
likáció során a két különböző címtártartalmat megpróbál- 
juk egységesíteni. Alapvetően három eset fordulhat elő: 

s Az esetek elsöprő többségében semmi gond sincs a tar- 
talomegyesítéssel, a módosítások nem zavarják egy- 
mást. A két, egymástól távoli gépen olyan módosítások 
keletkeztek, melyek teljesen függetlenek egymástól. Az 
egyik gépen mondjuk létrejött egy új felhasználó, a má- 
sikon pedig törölték X. Y. telefonszámát. 

" Néhány esetben a módosítások egyazon objektum kü- 
lönböző tulajdonságaira irányulnak. Az egyik gépen ki- 
tiltjuk Samukát, a másik gépen kivesszük őt egy csoport- 
ból. Az Active Directory jól átgondolt replikációs straté- 
giája miatt ezekben az esetekben sincs gond, ugyanis az 
átvitt adatok legkisebb egysége nem egy komplett ob- 
jektum, hanem annak egyetlen piciny attribútuma. 

" Lényegesen ritkábban ugyan, de előfordul, hogy a mó- 
dosítások ütik egymást: egyszerre két helyen ugyanazon 
az objektumon ugyanazokat az adatokat módosítják. 
Ilyenkor nincs ,jobb" megoldás, az Active Directory au- 
tomatikusan a későbbi módosítást érvényesíti a címtár- 
ban. 

: Vannak olyan esetek, amikor a két módosítás teljesen 
ellentmondásos helyzetre vezetne. Ilyen eset, ha az 
egyik gépen új felhasználót teszünk egy olyan szerveze- 
ti egységbe, melyet a másik gépen gyorsan letörlünk. A 
replikációs konfliktus feloldásának egyik lehetséges 
megoldása az lenne, hogy az új objektum a ,levegő- 
ben" jön létre, hisz kirántották alóla a szervezeti egysé- 
get. Vagy egyáltalán ne jöjjön létre? Ezt az esetet koráb- 
ban részletesen is elemeztem, így csak utalok a megol- 
dásra: az objektum a Lost and Found (talált tárgyak osz- 
tálya) tárolóba kerül. 

s És végül, de utolsósorban vannak olyan adatok, ahol má- 
sodpercekig sem engedhető meg az ellentmondás. Eze- 
ket az adatokat az AD nem engedi egynél több tarto- 
mányvezérlőn módosítani. Ilyen például a gyermektarto- 
mányok bejegyzése: egy pillanatig sem fordulhat elő, 
hogy két azonos nevű gyermektartomány létezzen, mert 
ezt a konfliktust a későbbiekben képtelenség feloldani. 
Az ilyen adatok számára az AD-ban egyetlen kijelölt mó- 
dosítási pontot találunk. 

A többforrású módosítás úgynevezett laza konzisztenciát 
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eredményez, ami azt jelenti, hogy a címtár minden adott 
pillanatban tartalmazhat olyan adatot, melyről majd ké- 
sőbb derül ki, vajon megfelel-e a tárolás szabályainak. De 
vannak adatok, amelyeknél nem engedhető meg egyetlen 
másodpercnyi bizonytalanság sem, nem ,ér rá" percekkel 
később megtudni, hogy befogadhatók-e. Ezeket az adato- 
kat az arra kijelölt pontokon módosíthatjuk: a FSMO- 
gépeken. 


FSMO szerepek 

A bevezetőben felsorolt öt FSMO-szerep közül kettő erdő- 

három pedig tartományszintű. Az erdőszintűekből az egész 

AD-erdőben egyetlenegy van, a tartományszintűekből vi- 

szont tartományonként egy-egy. (A tartományszintűek rep- 

likációs határa egy adott tartományra korlátozódik.) Rövi- 
den vegyük őket sorra: 

s PDC Emulator. A leggyakrabban hivatkozott, tartomány- 
szintű FSMO-szerep, pedig ennek a kis kakukktojásnak 
nem is adatmódosítási, hanem kompatibilitási szem- 
pontból kell egyedül állnia. A régi ügyfelek (Win95, Me, 
NT34) ugyanis azt hiszik, minden tartományban van 
Primary Domain Controller, és csak ezt bízzák meg bi- 
zonyos módosításokkal, például jelszóváltoztatással. Ha 
nekik ez kell, hát ,van" PDC. Emellett a szerep hordo- 
zója lesz a Domain Master Browser, a GPO Master és az 
időmester is. Négyet egy csapásra! 

A PDC Emulator tartományszintű szerep. 

s RID Master. Az NT4-es címtárban (SAM) nem okozott 
gondot egyedi azonosítók (SID-ek) létrehozása, mivel 
csak egyetlen helyen, a PDC-n jöhetett létre objektum. 
Elosztott módosítási környezetben viszont már jelentős 
kihívás az itt-ott létrejövő objektumok azonosítóinak 
egyediségét biztosítani. Ezt az AD-ban úgy oldották 
meg, hogy továbbra is központi helyen találjuk a SID- 
gyárat, s a többi tartományvezérlő kétszázas csomagok- 
ban szállítja el a kész azonosítókat. Amikor új objektu- 
mot hozunk létre, az úgynevezett RID (Relatíve Id) 
poolból kapunk egyedi azonosítót. 

A RID Master tartományszintű szerep. 

s Infrastructure Master. Ez a jószág a kócos tartományi 
adatok kifésüléséért felelős. Mitől válhat, sőt válik kó- 
cossá az AD tartalma? Attól, hogy az LDAP-szabványnak 
megfelelően hierarchikus felépítésű, de valójában adat- 
hálót tárol! Gondoljunk csak a felhasználók csoporttag- 
ságára: egy júzer több csoport tagja lehet, s egy csoport- 
ban számtalan tag szerepelhet. Ez tipikus many-to- 
many reláció, amit az AD úgy tárol, hogy mindkét fél 
.tudja", kikkel áll kapcsolatban. Ráadásul - a rendszer- 
gazdák életének megkönnyítésére — az összerendelési 
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adatok mindkét helyen módosíthatók. Ha egy felhasz- 
nálón átállítom a csoporttagságot, a csoporton , után kell 
húzni" a megfelelő (Member) attribútumot, hogy a rend 
helyreálljon. Ez fordítva is igaz: ha egy csoportból kiha- 
jítunk valakit, az eltávolított objektum MemberOf attri- 
bútumát illik korrigálni. 

Az Infrastructure Master tartományszintű szerep. 





Rendszergazda 





2. Módosítás végigvezetése 


Infrastucture Master 


kd Az Infrastructure Master elvégzi helyettünk a módo- 
sítások átvezetését, a konzisztencia megórzését 


s Schema Master. Az objektumok tulajdonságkészletét a 
séma írja le. Ez egyetlen másodpercig sem lehet zavaros 
állapotban, mert akkor zavaros, önellentmondást hor- 
dozó objektumok születhetnének a címtárban. Nem le- 
het lebegtetni az a kérdést, hogy vajon a személyi szám 
attribútum numerikus vagy string típusú-e? A séma bő- 
vítését egyébként eléggé megnehezítették számunkra: a 
megfelelő MMC modul (schmmgmt.dll) települ ugyan, 
de nem regisztrálódik, csak a Schema Admins csoport 
tagjai jogosultak a módosításra stb. 

A Schema Master erdőszintű szerep. 

s Domain Naming Master. Gyermektartomány vagy új fa 
telepítésekor az AD igen egyszerű módon gondoskodik 
a nevek egyediségéről: a Domain Naming Master dönti 
el, hogy az új jövevény beléphet-e. Ha ezt tudjuk, nem 
meglepő, hogy a DCPROMO-.EXE erőteljesen támaszko- 
dik erre a szerepre, s ha nem találja az erdőben, nem 
tud telepíteni. Számos Knowledge Base cikk szól erről. 
.NET Server 2003 újdonság: a Domain Naming Master 
lehetővé fogja tenni tartományok és DC-k átnevezését! 
(Hogy ehhez mit fog szólni egy Exchange Server, azt 
egyelőre ne firtassuk.) 

A Domain Naming Master erdőszintű szerep. 


Mit kell tenni az FSMO kiszolgálókkal? 


Normális üzemeltetési körülmények között az égvilágon 
semmit. Ha azonban valamelyik FSMO-gép elromlik, vagy 
le kell állítanunk, záros határidőn belül pótolnunk kell a ki- 
esett szerepeket. A gondos gazda például úgy vonja ki a 
hálózatból a Schema Mastert, hogy előzőleg ezt a FSMO- 
szerepet átviszi egy másik tartományvezérlőre. A tervezett 
átvitelt FSMO-transfernek nevezik. Ebben az esetben a je- 
lenlegi FSMO-tulaj szabályos átadás-átvétel keretében vo- 
nul nyugállományba. 

Nem várt gépkiesés esetén a szerep szabályos átvitelére 
nincs mód. Ha biztosak vagyunk abban, hogy a hiányzó 
gép sohasem kerül vissza a tartományba (mert ellopták, ki- 





gyulladt stb.), az előző, eltűnt , tulaj" enge- fa) 
délye nélkül is átvihetjük a szerepet egy má- 

sik gépre. Ez a seize (hatalomátvétel) mód- M-I 
szer. Ha lehet, kerüljük ez utóbbi megol- 1 

dást, mert ha a halott gép mégiscsak feltá- 

mad, két masina is azt fogja hinni hogy ő az X-Master. Ezt 

a hibát csak az élőhalott újbóli megölésével korrigálhatjuk. 

A szerepek átvitele (transfer) grafikus, míg a hatalomátvétel 
(seize) parancssori eszközzel végezhető el. Ebből is látszik, 
hogy ez utóbbi módszer nem annyira támogatott. 


Transfer 


A múltkor felvillantottam, hogy az ADUC-ban (Active 
Directory Users and Computers) hol találjuk az FSMO- 
szerepeket: jobbklikk a tartományon, Operations Masters. 






The ogeraos master managos tha alocakan Gt RID poct: to other domain 
orias Úgy ore seret a domain padomne IR Kös 






Operaliona master 

fee ű 
ekszlette együknetmeátsüíeto tálteéra Tsai 
EGESZ ES sze zasz sie ea 








Domain operations masters 
FSMO-szerepek megtekintése, átállítása ADUC-cal 


Ugyanitt nemcsak megtekinteni, hanem — megfelelő jogo- 
sultságok birtokában — átállítani is lehet, melyik szerepet 
melyik tartományvezérlő lássa el. 

A Domain Naming Master az AD Domains and Trusts esz- 
közzel, a Schema Master pedig a Schema MMC snap-innel 
költöztethető. Ez utóbbihoz be kell regisztrálni a fentebb 
említett, megfelelő DLL-t: 


Regsvr32 schmmgmt.dll 
Seize 


Erőszakos hatalomátvétel. Ehhez az NTDSUTIL nevű pa- 
rancssori eszközt használhatjuk. Ennek parancskészlete, 
használata - talán szándékosan - annyira bonyolult, hogy a 
kisebb hitűek szakembert hívnak a feladat elvégzésére. 
Emlékszem, pár hónapja a levelezési listákon közvetítette 
valaki hősies küzdelmét, s a többiek segítségével végülis két 
nap alatt megoldotta a problémát. Egy egyszerű PDC Emu- 
lator átvitel így nézne ki: 


Legközelebb a replikációról mesélek. 


Fóti Marcell 
marcellf onetacademia.net 


MZ/X 
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Sémamódosítás plusz 
adatmódosítás 


Az Active Directory nemcsak , gyári" adatok tárolására képes, hanem a séma bővítésével tetszőleges to- 
vábbi attribútumok adhatók a meglévő objektumokhoz. Felvehető a címtárba például a felhasználók sze- 
mélyi száma, a számítógépek gyártási száma, a felhasználói csoportok gazdasági adatai stb. 


A séma bővítése a megfelelő jogosultságok birtokában egysze- 
rű feladat. A probléma ott jelentkezik, hogy ezt követően a fel- 
használói felület elemei (pl. Active Directory Users and 
Computers, ADUC) nem veszik észre" a változást, azaz a friss 
attribútumok meg sem jelennek a felhasználói felületen — nem- 
hogy módosítani lehetne őket. További munkabefektetésre van 
szükség ahhoz, hogy az új adatok hozzáférhetőkké váljanak. 
Egyik lehetőség az ADUC tuningolása. Ehhez sajnos COM- 
objektumot kell faragni, amivel két baj is van: 


. Valódi programozói munkát követel 
" Csak az ADUC felhasználói, vagyis tipikusan a rendszergaz- 
dák élvezik az előnyeit 


Ezt a lehetőséget tehát elvethetjük (úgysem sikerülne az a 

COM-objektum ;), más megoldás után kell néznünk. Sajnos 

nincs olyan varázsló a Windowsban, amelyik ismerné a kibő- 

vített sémaelemek megjelenítésének bűbáját, így a ,progra- 

mozó rendszergazda" vízió jegyében scriptírásra fogunk fanya- 

lodni. 

S ezzel két legyet ütünk egy csapásra. Miért? Mert a jó öreg 

VBScript-kód némi módosítással ASP-kóddá alakítható, így a 

kikísérletezett kód minimális változtatással weblapba ültethe- 

től Az ASP-technológia ráadásul megadja az adatok módosítá- 

sának kulcsát is: webes űrlapokat faraghatunk, melyen át 

könnyűszerrel töltögethető az AD. 

Ebben a cikkben tehát teljes körű megoldást mutatok a séma 

kreatív felhasználására. Teljes körű alatt azt értem, hogy telje- 

sen működni fog, de tudom, hogy más módszerek hasonlókép- 

pen célravezetőek lehetnek. Célom, hogy olyan sablonokat ad- 

jak a Kedves Olvasók kezébe, amellyel könnyen el tudnak in- 

dulni saját, nagyszabású címtáralkalmazásaik megírása felé. 

A lépések a következők: 

1. Sémabővítési előkészületek. A Schema Management snap- 
in regisztrálása. 

2. OID generálása. A sémabejegyzések egyedi azonosítóval 
rendelkeznek. Honnan szedjünk azonosítót? 

3. Új attribútum felvitele a sémába. Az attribútumok független 
elemként jönnek létre. 

4. A User objektum kiegészítése. A függetlenek függővé téte- 
le. 

5. Az új attribútum kilistázása VBScripttel. Ötsoros ADSI- 
script a címtár tartalmának kilistázására. 

6. Az új attribútum kilistázása ASP-lapon. Az előző ADSI-script 
web-lapba gyömöszölve. 

7. ASP adatbeviteli űrlap. Egyszerű űrlapot készítünk a felhasz- 
nálók számára. 

8. ASP-kód a címtár módosítására. Az űrlap által összegyűjtött 


adatok bevitele a címtárba. 
9.A megfelelő jogosultságok beállítása. NTFS-jogok? 
Címtárjogok? 


Sémabővítési előkészületek 

A séma bővítéséhez eszköz kell. A Schema Management nevű 
MMC snap-in megteszi, csak éppen nem működik, amíg be 
nem regisztráljuk: 


regsvr32 schmmgmt.dlil 


Ezután a parancs után megjelenik az MMC-modulok között a 
sémabővítési eszköz. 


tele Elgetieető-ü tal 


GAKONSLSSSETS ESŐS SSL: d A schmmgimt. dí/ regisztrá- 


ciója után megjelenik az 
MMC-modulok közt a séma- 
szerkesztő 


S Active Directory Domains and Trusts 





Gő Active Directory Sites and Services 
Active Directory Users and Computers 


Csak a Schema Admins csoport tagjai jogosultak a séma bőví- 
tésére. Még egy buktató: ha nem a Schema FSMO-szerepet 
futtató gépen próbálkozunk, hibaüzenetet kapunk: 


ez xi 


5chema update is not allowed on this DC. Either the registry key is not set or the DC is 
Owner, 


not the schema FSMO Role 
fi 


Error 





Id A séma csak a Scherma Masteren bővíthető; 


Ez az üzenet akkor is felbukkanhat, ha a Schema 
Managerben nincs bepipálva az Operations Master menü- 
pont mögötti ablakban a , The Schema may be modified..." 
pipa. Alapértelmezésben nincs bejelölve. Körkörös védelem 
a sémabővítés ellen. 


OID generálása 

Új attribútum felvitelekor a séma bővítése két lépésből áll. Elő- 
ször az attribútumot, mint önálló, független bejegyzést kell 
megalkotni, s ezt követheti az objektumhoz csatolási lépés. A 
független, ide-oda csatolható attribútumok előnye, hogy több 
objektum is rendelkezhet azonos attribútummal anélkül, hogy 
többször létre kellene azt hozni. Többszörösen, sőt minden 
objektumon felhasznált attribútum például az X.500-útvonal 
(DN, illetve a relatív név (CN). 

A séma módosításához egy-két dolgot előre el kell döntenünk: 
mi legyen az új attribútum neve? Mi legyen az adattípusa 
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(Distinguished Name, Case Sensítive String, Case Insensitive 
String, Boolean, Integer, SID)? Ezek még a könnyebben el- 
dönthető kérdések. 

Nehezebb válasz adni erre a kérdésre: mi legyen az objektum 
OID-je? 

Mi is ez az OID? Egy, az ISO-testület által kiosztott iparági azo- 
nosító. Az attribútum létrehozásakor az OID-mező kitöltése 
kötelező. Ha belekukkantunk a sémába, ilyen OID-ket látha- 
tunk a gyári attribútumokon: 


1.2.840.113556.1.5.4.1307 


Ennek értelmezése balról jobbra a következő: 
1-ISO 
2-ANSI 
840—-USA 
113556-—Microsoft 
1-Active Directory 
5-Classes 
4-Builtin-Domain 
továbbá egy attribútumsorszám. Ez eddig szép, de honnan 
akasszunk le magunknak ilyen azonosítót? Ajánlott a Resource 
Kit megfelelő eszközével (OIDGEN.EXE) generálni egyet, vagy, 
ha megígérjük magunknak, hogy soha nem veszünk 
címtáralapú alkalmazást, akár hasraütéses módszerrel is dol- 
gozhatunk. Például a 1.2.840.111111.1.5.x (objektumosztá- 
lyok), illetve a 1.2.840.111111.1.4.x (tulajdonságosztályok) 
tartományokat használhatjuk kiindulási alapként. Ezzel össze- 
ütközésbe kerülünk az 111111 azonosítójú céggel, de ha az 
nem az informatika területén működik (az ISO azonosítók az 
összes iparágra kiterjednek), akkor kicsi az esélye, hogy bármi- 
kor belénk botoljanak a saját címtárunkban. 


Új attribútum felvitele a sémába 

A Schema snap-inben jobbkattintva az Attributes csomópon- 
ton válasszuk a Create New Attribute menüpontot. Az alábbi 
látványban lesz részünk: 


Create New Attribute MEE(zi2d 


EZ Create a New Attibute Object... 
Identification 
Common Name: SzSz 


LDAP Display Name: [SzSz 


Unigue X500 Object ID: 











IT MultiValued 


bo] cma ] 


Id A séma bővítése , személyi szám" (szsz) mezővel. A har- 
madik sor az ominózus OID-érték 





Töltsük ki a Common Name (CN) és Display Name mezőket 
az új attribútum nevével, az OID legyen az, ami, az adattípus 
(személyi szám esetén) legyen Case Insensitive String, mini- 
mum- és maximumértékeket ebben az esetben nem tudunk 
megadni. Kattintsunk az OK gombra, és az attribútum létre- 
jön. Hol? A levegőben. Vagyis egyelőre nem kapcsolódik se- 
melyik objektumhoz. 





A User objektum kiegészítése 


A vadonatúj ,szsz" attribútumot kapcsoljuk 
most hozzá a User objektumhoz! Válasszuk ki 
a Classes csomópontot a baloldali fában, s a 
jobboldalon felsorakozó kismillió objektum 
között keressük meg a Usert! Kettő kattanás, 
és megnyílik. Az Attributes fülön a felső kockában sorakoznak 
a User objektum kötelezően kitöltendő attribútumai (lám-lám, 
egy sincs ilyen, mindegyik máshonnan öröklődik!), az alsóban 
pedig az opcionálisak. Ide kell felvennünk a , szsz" mezőt. Az 
alábbi ábrán látható, hol kell lennie, ha ügyesek voltunk: 


General ] Relationship . Áttibutes ] Security ] 














Ed A User objektum opcionális mezői közé felvettük a 
nSZSZ(, azaz személyi szám mezőt 


Az új attribútum kilistázása VBScripttel 

Most jön a neheze. Az új attribútum ugyanis sehol sem jelenik 
meg a felhasználói felületen. Ha nem teszünk semmit, ez így 
is marad. Azonban az alábbi kóddal könnyedén kilistázhatjuk 
a teljes címtárból a , szsz"-attribútumokat: 





Ez a kód az [1] címről tölthető le (szszlist.vbs), és a tartomány 
LDAP-útvonalának aktualizálása után vidáman listázza a sze- 
mélyi számokat - feltéve, hogy a Kedves Olvasó is elvégezte 
a címtármódosítást. Ha ez nem történt meg, ismeretlen att- 
ribútumra való utalással a programocska leáll. 

Némi magyarázatot adok kódról. Ebben a VBScript-kódban az 
Active Directory Services Interface (ADSI) COM-objektumku- 
pac segítségével tevékenykedünk a címtárban. Az ADSI a ma- 
ga hierarchikus formájában teszi elérhetővé számunkra a cím- 
tárat, s ehhez csak a kezelni kívánt objektum LDAP-útvonalát 
kell ismerni. 

A GetObject() függvény egy objektumkezelőt (handle) ad vissza 
a paraméterként megadott LDAP-útvonalon található objek- 
tumhoz, legyen az felhasználó, csoport vagy szervezeti egység. 
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mi 


A mi esetünkben ez a kezelő a Users tároló- 
ra mutat. A második sorban a kezelő által el- 
ért objektumokat leszűkítjük a felhasználó- 
objektumokra (filter). Ennek köszönhetően a 
harmadik sorban kezdeményezett ciklus 
csak User típusú objektumokat fog érinteni. 
Meglepő módon Computer objektumokat is ki fog listázni, 
ami bizonyos összefüggésre utal e két objektumtípus között. A 
for each — next ciklus végigfut az emberek-handle gyermekob- 
jektumain, s a wscript.echo sorban kiírja a kimenetre a megta- 
lált objektumok nevét és szsz attribútumát. 

Remélem nem meglepő, hogy a listában a szsz mező nem sze- 
repel, hisz mindenütt üres. Nem töltöttük még fel, mivel nincs 
mivel! De egyelőre örüljünk ennek a kis sikernek, és a listázá- 
si funkciót vigyük át a webre! 
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Az új attribútum kilistázása ASP-lapon 

Aki még sohasem alkotott ASP-weblapot, azok kedvéért mondom 
el, hogy itt egy olyan HTML-lapról van szó, amelyik VBScript (vagy 
más scriptnyelvi kód) szigeteket tartalmaz —90 és 962 ,zárójelek" 
között, ahogy azt az alábbi ábra bal oldalán láthatjuk: 


HEH 


ASP-motor 


— 


c9oaz141997 


Script-szigetek a HTML-tengerben: ez az ASP! 








A csoda akkor következik be, amikor ezt a lapot átszivattyúzzuk 
az IIS-webszerver ASP-motorján, vagyis ráböngészünk egy URL 
segítségével. Ekkor ugyanis a kódszigetek lefutnak, és HTML-lel 
tapasztják be azt a helyet, ahol korábban ők voltak. A kimenet 
pedig tiszta HTML-kód lesz. (Ha csak egyszerűen megnyitjuk a 
böngészővel a fájlrendszerből az ASP-lapot, a csoda nem követ- 
kezik be, mert ha a lap nem IIS-től kerül hozzánk, nem jut szó- 
hoz az ASP-motor, s a szigetek szigetek maradnak.) 

Ennyi ismétlés után lássuk azt az ASP-lapot! Ehhez körülbelül 
annyit kell tennünk, hogy az előző kódot 98 és 965 jelek kö- 
zé zárva behányjuk egy .ASP-kiterjesztésű weblapba, illetve a 
kiíratást kicseréljük olyan megoldásra (response.write), mely a 
weblapba ontja adatait. Az alábbi ASP-lap szintén az [1] címen 
található, neve: szszlist.asp. 


XHTML: 

SL BODY2 

Személyi számok listázása a címtárból 

24 

Dim ember, emberek 

set emberek- 

GetObject ( " LDAP : / /cn-users , deo-falatrax, 

dc-hu") 

emberek. filter-Array ("user") 

for each ember in emberek 
response.write ember.name 
response.write " " 
response.write ember.szsz 
response.write "cbr:" 

next 

sz 

Lista vége! 

4a/BODY5 

€a/HTML2 
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Ezt a kódot mentsük le az InetPublwwwroot könyvtár alá, és 
hívjuk meg böngészőnkből a http://gepemvszszlist.asp címen! 
Lefut? Ez az Active Directory biztonsági beállításaitól függ. 
Ugyanis az IIS egy speciális felhasználó, az IUSR gepnev nevé- 
ben futtatja az azonosítatlan (anonymous) felhasználók által le- 
töltött kódot. Ennek a furcsa nevű felhasználónak csak abban 
az esetben van legalább listázási joga az Active Directoryn, ha 
mindenki másnak is Read joga van — azaz az AD telepítésekor 
NTA4-biztonságra voksoltunk. Ekkor ugyanis a tartomány gyöke- 
rén Read joggal megtalálható a , Pre-Windows 2000 Access" 
nevűcsoport, melynek tagja az Everyone, melynek tagja az 
IUSR gepnev fiók. Az alábbi ábra a Falatrax tartomány AD- 
jának gyökerén mutatja a jogosultságokat: 


Access Control Settings for falatrax 

















Domain Admins (FALATRAXNDOmai., Special This object only 


Administrators (FALATRAXMAdminist... Special This object and a 
SYSTEM Full Control This object only 
Enterprise Admins (FALATRAXNEnte... — Full Control This object and 











BENE 
Special 
Write Property 


Esztet 
Pre:Windoves 2000 Compatible Acc... 
Exchange Enterprise Servers (FALA. 


This object and 
User objects ] 


This object and a e 
p 


Id Miért képes az anonim felhasználó a címtár [istázására 
weben át? Mert így telepítettük az AD-t! 


Ha nem fut le a kód, hanem Access Denied hibaüzenetet ka- 
punk, vegyük el a szszlist.ASP fálj NTFS-joglistájából az 
Everyone csoportot, és tegyükbe helyette például a Domain 
Adminst, vagy bármelyik másik csoportot, melynek nem tag- 
ja az IUSR gepnev. Ez kikényszeríti az autentikációt, ezáltal 
megszünteti az anonim böngészést, és rendszergazdaként 
már bármit lekérhetünk a címtárból. Az eredmény ehhez ha- 
sonló: 


Fáj http://localhost/szszlist.asp - Microsoft Internet Expl. 
] Ele Edit Wiew  Favorites  Iools Help 
- 3 - OB űl €searh 6GFavorites 





] Address [] http://localhostjszszlist.asp 





Személyi számok listázása a címtárból 
CN-Administrator 

CN-Guest 

CN-IUSR ORA 


E A wszszlíistasp 
futásának eredmé- 


nye 





Lista vége! 


Ha már működik, vizsgáljuk meg a böngészőben megjelenő 
lap forrását! Tiszta HTML-t látunk, mivel az összes kód kifej- 
tődött! 

Természetesen ez a megoldás épphogy csak működik, mo- 
dellként, csontvázként használható. Komoly felhasználás 
esetén én tennék az elejére egy cx9OPTION EXPLICIT96- 
megszorítást, amely megvéd a nemlétező változók használa- 
tától, illetve a címtárelérést is körül kellene bástyázni hibake- 
zelő kóddal (ON ERROR). 

A személyi számok listája még mindig üres. Most már itt az 
ideje, hogy a módosítást is lehetővé tegyük. 


ASP adatbeviteli űrlap 
A webes adatfelvitel legalább két ASP-lapot igényel. Az egyik- 
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ből űrlapot készítünk, amely lehetővé teszi, hogy a felhasználók 
adatokat gépeljenek be, a másikat pedig az űrlap fogja meghív- 
ni a módosítás kivitelezése céljából. Kezdjük az űrlappal: 


SxHTML- 

SBODY5 

xFORM NAME-"szszform" 
ACTION-"szszmod.asp": 

A modositando felhasznalo LDAP-azonositoja: cbr: 

cxINPUT TYPE-"text" NAME-"FormObj" VALUE- 
"CN-Administrator, CN-Users , DC-Falatrax, DC-hu" 
size-"50"2cBR2 

Az uj szemelyi szam: cbr: 

cxINPUT TYPE-"text" NAME-"FormSzsz"5cBR5 

cxINPUT TYPE-"submit" VALUE-"OK"5 

€/FORM3 

£/BODY5 

c/HTML: 


METHOD-"GET" 


És kész. Letölthető az [1] címről, a fájl neve: szszform.asp, és 
így fest a böngészőben: 
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Address [£] http://localhost/szszform.asp 





A. modositando felhasznalo LDAP-azonosítoja: 


CNsAdrinistrator CN-:Users DC-Falatrax DC-hu 


Az uj szemelyi szar: 


ax] 


Id A szszform.asp úrlap működés közben 

A cFORM3 HTML-tag alakítja ki az űrlapot, melyen két 
mezőnk van. Az elsőbe a módosítandó felhasználó LDAP- 
útvonalát kell begépelni, a másodikba pedig a személyi szá- 
mot. A HTML-űrlapok kapcsolatmentességének következté- 
ben ez a lap önmagában nem képes elvégezni a módosításo- 
kat, minthogy letöltődése és böngészőbeli megjelenése után 
elszakad a kiszolgálótól. A FORM-tag viszont meg tud hívni 
egy másik lapot, amelynek a mezőértékeket is át tudja adni. 


ASP-kód a címtár módosítására 

Ez a lap a mi példánkban a szszmod.asp, melyet nem megle- 
pő módon az [1] címről lehet letölteni. Belsejében ismét némi 
ADSI-kódot találunk: 


SHTML: 

SLxBODY5 

3 

Dim ember 

set ember-GetObjectw("LDAP://":3reguest ( "Formobj" ) ) 
ember .szsz-cstr(reguest ( "FormSzsz") ) 
ember.setinfo 

$z 

A modositas vagy megtortent, vagy 
nem. A programozo nem irt 
hibakezelest 

£/BODY5 

4/HTML3 


Felhívom a figyelmet a paraméterek átvételére. Az ASP-lap a 
reguest objektumban kapja meg a hívó fél üzenetét, a beme- 
nő paramétereket. Ezek neve megegyezik az űrlapon használt 
mezőnevekkel (FormObj, FormSzsz). A GetObject tehát meg- 
kapja az űrlap , ormObj" mezőjének értékét, s ez alapján csat- 
lakozik a címtárhoz. Ezután a felhasználó , szsz" attribútumába 
beírjuk az űrlap második, ,FormSzsz" mezőjének értékét. 

Az ember.setinfo sor a módosítások véglegesítésére szolgál, ha 
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ezt a sort kihagyjuk, a címtármező tartalma érin- 
tetlen marad! 

Ha a listázásnál nem volt elegendő jogosultsá- 
gunk a címtár elérésére, akkor a módosításokhoz 
sem lesz. Ezt látjuk a böngészőben: 


7 


Technical Information (for support personnel) 
e Error Type: 

Active Directory (0x80070005) 

General access denied error 

/szszmod.asp, line 7 


Ezen a fájlon is dobjuk ki az NTFS-jogosultsági listából az Eve- 
ryone csoportot, és helyette a Domain Adminst tegyük be. Va- 
jon milyen NTFS jogosultsággal kellene rendelkeznie a Doma- 
in Adminsnak a címtár írásához? Meglepő módon elég a Re- 
ad, bár ennél nyilván többel rendelkezik. Vajon miért? 


A megfelelő jogosultságok beállítása 


Kik tudják használni jelenleg ezt a webalkalmazást? A listázás 
beindításához az ASP-fájlok NTFS-jogosultságait változtatgat- 
tuk. Mi köze ennek a címtárbéli jogosultságokhoz? 

Ha magán az ASP-fájlon nem tesszük lehetővé, hogy az IIS 
névtelen felhasználója, az IUSR gepnev olvasási jogosult- 
sággal rendelkezzen, a webkiszolgáló HTTP 404, Access 
Denied üzenettel válaszol a böngészőnek. Ezt megkapva az 
Internet Explorer azonosítási folyamatba kezd, és feldob egy 
bejelentkezési ablakot (kivéve, ha engedélyezve van a 
Windows Integrated azonosítási mód, mert ebben az eset- 
ben automatikusan behelyettesíti az aktuális Windows-fel- 
használónevet és jelszót), így megadhatjuk bejelentkezési 
nevünk és jelszavunk. 

Tehát az ASP-fájlok jogainak megkurtítása az azonosítás 
kikényszerítését szolgálja. A konkrét hozzáférési jogokat 
továbbra is az Active Directory joglistái (ACL) határozzák 
meg. A megfelelő jogosultságok beállításához tehát az 
ADUC szokásos lehetőségeit, jogosultságállítást, delegációt 
kell használni. 


Végezetül hadd emlékeztessek mindenkit arra, hogy a 
sémamódosítás — ma még — visszavonhatatlan folyamat. Ha a 
cikk olvasása közben valaki az éles címtárát bővítette személyi 
szám attribútummal, biztos lehet benne, hogy ez örökre meg- 
marad. Szólhattam volna előbb is...? 


Főti Marcell 
MZ/X 


marcellf onetacademia.net 


A cikkben szereplő URL-ek: 
[11 http://technet.netacademia.net/download/schema 
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VPN - Virtuális 
magánhálózatok 


2. rész, Az L2TP protokoll 


Az előző részben körüljártuk a VPN hálózatok , lényegét" 


, Windows 2000 kiszolgálónkon varázsoltunk 


egy VPN kiszolgálót és csatlakoztunk is hozzá — egyelőre csak egy munkaállomással, PPTP kapcsolaton 
keresztül. Ma terítékre kerül az új protokoll, az L2TP is. 


Az L2TP protokoll a PPTP és a Cisco által fejlesztett L2F (Layer 
2 Forwarding) protokollok összeházasításával született. Win- 
dows 2000-ben maga az L2TP protokolltitkosítást nem, csak 
az alagúthálózat kialakításához szükséges funkciókat tartal- 
mazza, így a ,csupasz" L2TP forgalom bár alagúton halad, de 
az alagút fala üvegből van. Szerencsére ezzel az ,üvegalagút- 
tal" nem találkozunk, ugyanis a Windows 2000 egy ügyes 
trükkel az LZTP tudomása nélkül titkosítja a hálózati forgalmat. 
A titkosítást a Windows IPSec motorja végzi, automatikusan 
generált szabályok alapján (amelyek kifejezetten az LZTP for- 
galom titkosítására készültek). 


Kapcsolódó IPSec cikksorozatunkban a dolog működéséről 
részletesebben is fellebbentjük majd a fátylat, egyelőre elé- 
gedjünk meg annyival, hogy az L2TP kapcsolat létrehozásához 
mind a kiszolgálónak, mind az ügyfélnek (azaz az alagút mind- 
két oldalának, mégpedig nem a felhasználónak, hanem a szá- 
mitógépeknek!) rendelkeznie kell egy-egy nyílt kulcsú tanúsít- 
vánnyal. Lehetőség van egyébként arra is, hogy a tanúsítvány 
helyett a kommunikáló tagok jelszóval hitelesítsék egymást, 
erről később lesz majd szó. 





3 zlOl2] 
] Action Ven [99 am BB? s 
Tree [ ! Systemlog 17 eventís) 
Event Viewer (Local) [mee ] [ 
1] Application Log edés db 
Lu szamtytog az 
3) System tog 
[] Fie Repbcation Service Event ] 
Date 9/23/2002 Source:  Remoleáccesr 1 
Time 1049 Categoyi None 
Type Waming —— EventiD: 20192 HED, 
User NZA ab 


Computer. MEMBERSRV 


Descipton 

Setőcata coukdrot be found Cormocione that use the LZTP protocol 

jet ese ásetatő ls VARNENOTÓL K ENKIÁOB BAlaCOKa altt kistt pó 
computer certificate No LZTP cals wil be accepted. 














Az RRAS minden induláskor ellenőrzi a számítógép ta- 
núűsítványát, és az eseménynaplóban jelzi, ha probléma van 
(esetünkben például nincs tanúsítvány) 


Alapértelmezésben, ha az RRAS kiszolgáló nem rendelkezik 
tanúsítvánnyal, az LZTP VPN kapcsolatokat meg sem kísérli 
felépíteni, úgysem sikerülne. Ilyenkor minden beérkező 
L2TP kapcsolatot azonnal elutasít. Erről a fenti ábrán is látha- 


tó csinos kis eseménynapló-bejegyzéssel tájékoztat minket. 


Tanúsítványok a számítógépen 


A számítógépnek is lehet tanúsítványa? Lehet bizony! Indít- 
suk el a Start menü Run parancsa segítségével a Microsoft 
Management Console-t (mmc.exe), majd válasszuk a Con- 
sole / Add/Remove snap-in... parancsot. A megjelenő ablak- 
ban kattintsunk az Add... gombra, a telepíthető modulok lis- 
tájában kattintsunk kétszer a Certificates sorra, majd vá- 
lasszuk a Computer account, majd a Local Computer opció- 
kat. Ezzel megnyitjuk a helyi számítógép tanúsítványtárát. Ezt 
az MMC konzolt egyébként későbbi használatra érdemes el- 
menteni. 
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(Emembersrv.falatrax.hu . Falatrax Enterprise CA 





z ÉJ certficates (Local Computer) 

7 (I Personal 
(A Certficates 

7 (I Trusted Root Certification Authorities 
CI certficates 

3. CI Enterprise Trust 

8 (I intermediate Certífication Authoríties 

4 CI REGVEST 

4-0 s 





Personal store contains 1 certficate, 


Id Ennek a számítógépnek van tanúsítványa... 
nan szerezte? 


vajon hon- 


A tanúsítványok kezelése-terjesztése Windows 2000 tarto- 
mányban igazán nem nehéz dolog. Ha valamelyik tagkiszol- 
gálóra telepítünk egy tanúsítványkiadó szolgáltatást 
(Enterprise, azaz vállalati üzemmódban), a Windows 2000 ki- 
szolgálók és munkaállomások automatikusan beszerzik tőle a 
megfelelő tanúsítványokat (mint az a fenti ábrán is látható). 
Ehhez egyetlen Group Policy beállításra van szükség (amit a 
tartományvezérlőre telepített CA egyébként meg is tesz): a 
mindenkire érvényes alapértelmezett tartományi házirend 
(Default Domain Policy) Computer Configuration / Windows 
Settings / Public Key Policies / Automatic Certificate Reguest 
Settings pontja alatt — ha még nem létezik — hozzunk létre egy 
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új Reguest objektumot. Az objektum típusa legyen Com- 
puter. Ezután már csak a használni kívánt CA nevét kell meg- 
adnunk -— a listában a tartományba telepített vállalati tanúsít- 
ványkiadók láthatók. 





Default Domain Policy (server falatrax.hu) Policy 
GR) Computer Configuration 
I] Software Settings 


(I Encrypted Data Recovery Agents 
AI Automatic Certificate Reguest Settings 
(DI Trusted Root Certification Authorities 
(D Enterprise Trust 

4) 8), IP Security Policies on Active Directory 
(4 CI Administrative Templates 
za ff User Configuration si 
(Automatic Certificate Reguest Settings store contains one autom ( 








Id Automatikus tanúsítványkérés beállításai a tartományi 
alapértelmezett csoportos házirendben 


A házirend érvényesítése után a Windows 2000 munkaál- 
lomások és kiszolgálók automatikusan beszerzik a nekik 
szükséges tanúsítványokat, sőt, idővel azok frissítésére is ké- 
pesek lesznek. A rendszer Windows 2000 tartományon be- 
lül szinte teljesen automatikus. Emlékszünk az előző cikk 
végén bemutatott két ábrára? Ott, míg a tartományon kívü- 
li Windows XP csak PPTP, a tartományi tag Windows 2000 
automatikusan L2TP protokoll segítségével csatlakozott a 
kiszolgálóhoz. A magyarázat ez: a Windows 2000 
Professional tartományi tag lévén hozzáfért a csoportos há- 
zirendhez, és az utasításoknak megfelelően telepítette a sa- 
ját kis tanúsítványát. 


Tanúsítványok telepítése , kézzel" 
No igen, de mit tehetünk, ha a fenti feltételek bármelyike 
nem áll fenn, azaz: 


, Nincs vállalati tanúsítvány-kiszolgálónk, vagy nem a sajá- 
tunkat szeretnénk használni 

, A számítógépek nincsenek tartományban, így automati- 
kusan kérni sem tudnak? 


Mindkét esetben kettős célunk van: az első, hogy vala- 
hogy tanúsítványhoz jussunk. Ehhez használhatunk bár- 
mely tanúsítvány-kiszolgálót, akár Windows 2000 CA-t is. 
A Windows 2000 tanúsítvány-kiszolgálótól a szolgáltatás 
webes felületén keresztül kérhetünk tanúsítványt, más 
szolgáltatások esetén érdeklődjünk a CA üzemeltetőjétől. 
A második cél pedig a megszerzett tanúsítvány telepítése. 
Ha a Windows 2000 CA-t használjuk (a webes felületen 
keresztül), ez automatikusan megtörténik, de ellenőriz- 
hetjük a számítógép tanúsítványtárában. Ha a tanúsít- 
ványt más szolgáltatótól kapjuk, ugyanitt importálhatjuk a 
rendszerbe. 


Tanúsítványkérés weben keresztül 

Lássuk mi a teendő, ha a Windows 2000 CA webes felüle- 
tén keresztül szeretnénk tanúsítványhoz jutni! Esetünkben a 
tartományon kívüli Windows XP-nek szeretnénk tanúsít- 


ványt szerezni. Ennek érdekében a böngé- 
sző segítségével megnyitjuk a CA weboldalát 
a http://server.falatrax.hu/certsrv címen (je- 
lentkezzünk be egy, a CA-hoz megfelelő jo- E 
gosultságokkal bíró tartományi rendszergaz- 

da nevével és jelszavával). 


ZA Microsoft Certificate Serrices- Microsoft Jotemet Explorer. 


Fin Edt View  Favortes Tools He 


Hm - 9 - (9 [3 


d / 


2 titpitiserver falatra hutcertsrei 


Welcome 





You use this web site to reguest a certificate for your web browser, e-mail cient, or other secure 
program. Once you acauire a certificate, you will be able to securely identify yourself to other 
people over the web, sign your e-mail messages, encrypt your e-mail messages, and more 
depending upon the type of certificate you reguest. 


Select a task: 
etrieve the CA certificate or certificate revocation list 
egyest a certificate 

O Check on a pending certificate 








Id A Windows 2000 CA webes felülete 


Ez valójában egy varázsló, amely lépésről lépésre végigvezet a 
tanúsítványkérés folyamatán. Tartsunk vele! 


s Válasszuk a ,Reguest a certificate" opciót, majd Next! 
s A következő oldalon válasszuk az , Advanced Reguest", az- 
után pedig a ,Submit a certificate reguest to this CA using 
a form" lehetőséget! 
Tie Et Vin Fevottes .Tods eb 


Hsa- 9 MJ Da sra 


2630 6) hitpilfserver fabatran.hujcertsrvicertrama ap 


nert fess E B 5 Ca 


Advanced Certificate Reguest 
Certificate Template: 


Adrrunostrator v 

















Key Options 
CSP: Microsoft Base Cryptographic Prouder vi 0. . 
Key Usage O Exchange O Signature O Both 


Key Size: [512 rona lermmonbey szer £12 1028) 


fe newkey set 
let the contamer name 

0 Use existing key set 

CT Enable strong pírvate key protection 

Cak keys as exportable 

7se local machine store 


You must be an administrator to generate 
a hey in the local machine store. 














Ed A kért tanúsítvány paraméterei 


A fent látható ,Advanced Certificate Reguest" oldalon a 
Certificate Template mezőben attól függően válasszunk tanúsít- 
ványtípust, hogy egyedülálló (stand-alone) vagy vállalati CA-hoz 
csatlakozunk. Stand-alone CA esetén a , Client Authentication 
Certificate" vagy az , IPSec Certificate" közül válasszunk (előbbi 
, felhasználó"-azonosításhoz is, utóbbi csak az IPSec csatornák 
kiépítéséhez használható), vállalati CA esetén pedig — mint az 
ábrán is látható — az Administrator típusú tanúsítványra lesz 
szükségünk. ú 

Aki nem hiszi, járjon utána [1]! Fontos még az ábra alján lát- 
ható másik bekeretezett rész: , Use local machine store", az- 
az a tanúsítványt a helyi számítógép tanúsítványtárába tele- 
pítsük. Ha a hozzá tartozó privát kulcsot később exportálni 
is szeretnénk (például adatmentési célból), válasszuk ki az 
egy sorral feljebb látható ,Mark keys as exportable" lehető- 
séget is. 


oCN.net working with windows / 2002. 10. 
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4 Microsoft Certificate Services - Microsoft Intemet Explorer 
Fe Ed View  Favortes Too Hep 


Dr 9 ADD Ps 


Favortes Klfímesa 2 


fsetár ess [ÉJ hetpedfserver falatra. hujcertsrvfcertfnsh. ap 





Certificate Issued 
The certificate you reguested was issued to you. 


stall this certificate 








Id A kész tanúsítványt egy kattintással telepíthetjük 


Miután a kérést elküldtük, a vállalati CA — megfelelő jogok bir- 
tokában — azonnal elkészíti a tanúsítványt, és a következő ol- 
dalon egy kattintással telepíthetjük is azt. Ha a CA nem válla- 
lati típus, várnunk kell addig, míg egy rendszergazda jóvá nem 
hagyja a kérésünket. Ezután visszatérhetünk a kiszolgáló 
weboldalára és hozzájutunk a hőn áhított tanúsítványhoz. 


További feltételek a tanúsítványokkal kapcsolatban 
A sikeres LZTP kapcsolat kiépítéséhez tehát mindkét tagnak 
rendelkeznie kell érvényes tanúsítvánnyal, bár mint a mellé- 
kelt ábra mutatta, az nem feltétel hogy az a bizonyos tanúsít- 
vány annak a , nevére" szóljon, aki azt használja (ettől persze 
ez még biztonságos, hiszen a privát kulcs csak nála található 
meg). A tanúsítvány érvényességét két tényező befolyásolhat- 
ja még: 

s A tanúsítvány lejárati ideje (ellenőrizhetjük, ha a tanúsít- 
ványra kettőt kattintunk) és egyéb jellemzői, pl. a visszavo- 
nási státusza 

s A tanúsítványt kiadó szervezetbe vetett bizalmunk 

No ez utóbbi már érdekes kérdés. Hogy kikben bízunk? 

Nos, a Windows beépítve tartalmaz egy listát a , megbízha- 

tó" tanúsítványkiadókról. Ezután minden olyan tanúsítvány- 

ban megbízunk, amit olyan CA adott ki, aki ebben a listá- 
ban szerepel, vagy legalábbis, ha a kiadó CA-nak van olyan 
saját tanúsítványa, ami végső soron egy ilyen listatagtól szár- 
mazik (azaz, a CA-k közti hierarchiában egy megbízott CA- 
nak ,gyermeke"). Ez a lista a megbízott gyökérkiszolgálók 
listája, . ,magyarul" a ,Trusted Root  Certification 


Authorities". 


Ta Local Computer Certifjcates - [Console RoptlCertífjcates (Local Computer) Wrusted Rogt Certif, . EJEJ60 





— ÉJ certíficates (Local Computer) 
- CT Personal 
(I Certficates 
7 ( Trusted Root Certfication Authorities 
A EZZTEEI 
EJ Enterpese Trust 
(DJ intermediate Certfication Authoríties 





(EFESTE, verfied Certs FESTE, Verfied Certs 
(ElFrst Oata Digtal Certficates Inc, ... . Frst Data Digtal Certficates. 
(EFMT Case 2 CA FNMT Case 2 CA 
(Eldobatsígn Root CA Gobalsgn Root CA 

Ö trusted Pubkshers (EJ GTE CyberTrust Global Root. GTE CyberTrust Global Root. 

J Urtrusted Certficates (EJGTE CyberTrust Root. "GTE CyberTrust Root. 

DÖ Tird-party Root Certfication Authoríttes . [E]GTE CyberTrust Root. "GTE CyberTrust Root. 

I Trusted People Ehttp:ffvnew.vabcert.comf hitpiffvwwewe. valcert comf 
s I Certificate Enrolment Regyests Edhttozffvnwe.valcert com 
s gspc 


hetp:f[vannw. valcert .comf 
bítp:fvrwww.valzert.comf 
1PS SERVIDORES 
. Merosoft Authentisodeítm) F 
Mirosoft Root Authorty S 
z 


[d Ellenőrizzük, hogy a házi CA-nk szerepel-e a megbízott 
győkérkiszolgálók listájában! 


Windows 2000 tartományi környezetben természetesen 
minden vállalati CA bekerül a bizalmi listába, és persze kéz- 
zel is vehetünk fel újabbakat. Tartományon kívül azonban 
érdemes figyelni, és ellenőrizni, hogy a saját CA-nk szere- 
pel-e ebben a listában. A webes tanúsítványtelepítés során 
ez a bejegyzés is létrejön, de ha mégsem, a tanúsítványki- 


working with windows 


adó weboldaláról letölthetjük az ő saját tanúsítványát, és 

kézzel importálhatjuk a listába. A lényeg, hogy meglegyen. 

Visszatérve a számítógépek saját tanúsítványaira: egy gép- 

nek több tanúsítványa is lehet, a sikeres csatlakozás feltéte- 

le az, hogy mindkét gép rendelkezzen legalább egy olyan 

tanúsítvánnyal, amely: 

. ugyanattól a tanúsítványkiszolgálótól származik 

e ráadásul ebben a közös tanúsítvány-kiszolgálóban mindket- 
ten megbíznak 

Ennyi. Pofonegyszerű, nemde? :-) 


Hálózatok összekapcsolása VPN-en keresztül 


Eddig (gondolhatnánk) arról volt szó, hogy mi módon csatla- 
koztathatunk egy-egy számítógépet, munkaállomást a vállalati 
hálózathoz virtuális magánhálózaton keresztül. 


I VPN-kapcsolat 





" Állandó vagy Állandó 
Fiókiroda modemes internet- Vállalati 
hálózata internetkapcsolat . kapcsolat hálózat 
10.2.2.x 10.1.1.x 


Ed Alhálózatok összekapcsolása VPN-nel 


A valóság az, hogy ha nem egy számítógépet, hanem egy 
teljes alhálózatot csatlakoztatunk, a módszer teljesen hason- 
ló, csak a virtuális magánhálózatot nem az egyes számítógé- 
pek, hanem az alhálózat , határán" álló RRAS kiszolgáló épí- 
ti fel — a másik alhálózaton található másik RRAS kiszolgáló 
felé. Az RRAS kiszolgálók feladata, hogy a túloldali alhálóza- 
tokba haladó illetve onnan érkező csomagokat a megfelelő 
módon továbbítsák (routolják). Ezt a hálózati konfigurációt 
ezért router-to-router VPN kapcsolatnak is nevezik. 
Létrehozhatunk , féloldalas" hálózatot is, amikor mindig 
csak az egyik oldal (általában a fiókiroda) kezdeményezi a 
kapcsolatot, amikor arra igény van. A fiókiroda RRAS szol- 
gáltatása ilyenkor csak , ügyfélként" üzemel, a VPN szolgál- 
tatást csak a központi RRAS-ra kell telepíteni (akit hívunk). 
Állandó internetes kapcsolatra is csak a központi szolgálta- 
tásnak van szüksége, a fiókiroda ugyanis azt saját magának 
képes igény szerint kiépíteni (pont ugyanúgy, mint az ügy- 
fél, aki a VPN-re való csatlakozás előtt tárcsázza az Internet- 
szolgáltatóját). Ha az állandó kapcsolat mindkét oldalon 
megvan, létrehozhatjuk a szimmetrikus VPN-t is. Ebben az 
esetben mindkét RRAS kiszolgáló egyidejűleg VPN kiszolgá- 
ló és ügyfél is, a kapcsolat kiépítését pedig mindig az kezde- 
ményezi, aki éppen szeretne , átlátni" a másik alhálózatba. 
Honnan tudja az RRAS, hogy VPN kapcsolatot kell (lehet) ki- 
építeni, kivel, milyen módon? Honnan tudja az RRAS hogy mi 
van a ,másik" alhálózatban? Honnan tudja az RRAS, hogy a 
másik alhálózatot a VPN kapcsolaton keresztül érheti el? Ezek- 
re a kérdésekre kell sorban választ adnunk néhány varázsló 
segítségével. 


Új demand-dial kapcsolat létrehozása 

Tegyük fel, hogy a feladat a fentebb látható két alhálózat (a 
központi 10.1.1.x és a vidéki 10.2.2.x) összekapcsolása. Ehhez 
mindkét kiszolgálóra telepítettük és konfiguráltuk már az 
RRAS szolgáltatást, VPN kiszolgáló üzemmódban. Természe- 
tesen rendelkezésünkre állnak az LZTP használatához szüksé- 
ges tanúsítványok is. A következő lépés, hogy létrehozzuk a 
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VPN automatikus felépítéséhez szükséges elemeket mindkét 
kiszolgálón. Ezek: 


e Egy úgynevezett , demand-dial interface", ami gyakorlati- 
lag megfelel az ügyfélgépeken a telefonos hálózati kap- 
csolat ikonjának, csak ezt az RRAS képes automatikusan 
tárcsázni 

s Egy felhasználónév arra az esetre, ha a távoli RRAS sze- 
retne bejelentkezni hozzánk 

s Egy bejegyzés az útválasztási táblában, ami jelzi, hogy a 
távoli alhálózat a demand-dial kapcsolat túloldalán talál- 
ható 


Először hozzuk létre a VPN interfészt. Üljünk le a vidéki szá- 
mítógép elé, és az RRAS konzolban a Routing Interfaces sorra 
kattintva válasszuk a , New demand-dial interface" parancsot! 


GEYTTTOZITETTTTETT 


Welcome to the Demand Dial 


Routng and Remete Art 
beg ss Interface Wizard. 


EJ Server Status. 
7 ED MEMBERSRV (loca) 


Using tíz wizőrd you can cieate a demand dal mtertace to 
connect this router to other tövtetz. 


Piezz Next to continue. 
ÁT szatk Route 
ZA OMcP Relay Age 
A ien 
7 ÚGY Remote Access Polc 
8 Ő Remete Access Log 





Id Az új VPN interfészt létrehozó varázsló 


A varázsló első kérdése a létrehozandó kapcsolat nevére vo- 
natkozik. Azt hihetnénk, hogy bátran választhatunk bármit, 
azonban vigyázzunk: ha nem csak kitárcsázni szeretnénk, 
hanem a behívást is engedélyezzük, a varázsló ezt a nevet 
fogja adni a túloldali eszköz számára létrehozott felhaszná- 
lónak. Ezért érdemes olyan nevet választani, ami utal a túl- 
oldali eszközre, nem tartalmaz szóközt és ékezetes betűket. 
Miután mi a vidéki router előtt ülünk, a név most legyen: 
,KozpontiRouter". Ezután kiválaszthatjuk a kívánt VPN pro- 
tokoll típusát: PPTP, LZTP vagy automatikus, majd meg kell 
adnunk a túloldali VPN kiszolgáló külső IP címét, ahova az 
alagutat építeni fogjuk. 


Demand Dial Interface Wizard HT 


Protocols and Security 
Select ttansports and security options for this connection. 





Check allthat apply: 
[7 Route IP packets on this interface. 
I RoutelPx packets on this interface. 
[7 Add a user account so a remole router can dial in. 
F 
FE Use scfptna 


ad ff that ís the 








Ed AHozzunk-e létre helyi felhasználói fiókot a betárcsázó 
router számára? 


Ezután az ábrán is látható oldal következik: kérhetjük az IP 
és IPX csomagok továbbítását a kapcsolaton keresztül, vala- 
mint megkérhetjük a varázslót, hogy hozzon létre helyi fel- 
használót a távoli routertől beérkező hívások számára. Fi- 
gyeljünk rá, hogy ez a felhasználó tagkiszolgálók esetén nem 


tacrb 
kot 


LECI 


Jet 


f 








az Active Directoryba, hanem a számítógép 

saját felhasználói adatbázisába kerül! Erre 

akkor kell figyelnünk, amikor majd a túlolda- 

lon meg kell adnunk a betárcsázáshoz szük- 

séges felhasználónevet, jelszót és tarto- 

mányt: ez utóbbi ekkor nyilván nem a Win- 

dows tartomány, hanem a számítógép neve lesz. (Természe- 
tesen a behíváshoz nem feltétlenül kell az így létrehozott 
felhasználóneveket használni, bármilyen fiók — tartományi is 
— megfelel, ha rendelkezik a megfelelő behívási jogosultsá- 
gokkal). 


A következő két oldalon meg kell adnunk először az újonnan 
létrehozott felhasználó jelszavát, majd a kitárcsázáshoz szük- 
séges adatokat: felhasználónevet, tartományt és jelszót. A 
VPN interfész ezzel elkészült. Végezzük el ugyanezeket a mű- 
veleteket a másik kiszolgálón is (persze értelemszerűen az el- 
lentétes neveket választva). Az interfész ettől a pillanattól 
kezdve — bár még nem automatikusan, de kézzel — már csat- 
lakoztatható. 














Roszng nd Remote Aecess 
1 server Szatus 





7 TŐ SERVER (oca) Connected 
E tte kétess Connected 
A pemete kezes Carts (0) Cornedted 
Parts connected 
A ige 
47 Remete hetest Pokoes 
5 (Ő Remete keress 109909 
2] 


Corneet 





Id Az interfész kézzel máris használható 


A Connect parancs segítségével próbáljunk aktiválni a VPN 
kapcsolatot. Ha munkánkat jól végeztük, néhány másod- 
perc alatt a kapcsolat bármelyik irányba (de nem egyszer- 
re!) kezdeményezve kiépül. Ezt az interfész Connection 
State oszlopának , Connected" értéke jelzi. Ha a csatlako- 
zás nem sikeres, az , Unreachability Reason" (és az ese- 
ménynapló) elárulja nekünk, hogy mi lehet a probléma. Ha 
a felhasználónév / tartomány / jelszó nem megfelelő (emlé- 
kezzünk, hogy a varázsló csak akkor hoz létre tartományi 
felhasználót, ha az RRAS tartományvezérlőn fut), akkor a 
Set Credentials... parancs segítségével újra megadhatjuk 
ezeket az adatokat. 

Végül a Properties hatására előbukkanó dialógusablakban el- 
lenőrizhetjük és módosíthatjuk a varázslóban megadott és 
egyéb tulajdonságokat (például hogy mennyi idő múlva sza- 
kítsa meg a kapcsolatot, ha nincs forgalom rajta). Figyelem! 
A VPN kapcsolat mindig legyen demand-dial, de a várakozá- 
si időt kikapcsolhatjuk. Érdemes az újratárcsázási beállításo- 
kat is áttekinteni. 

Ne ijedjünk meg, ha a sikeresnek tűnő csatlakozás után a 
Remote Access Clients továbbra is 0 kapcsolatot jelez, a 
router-to-router kapcsolatot az RRAS itt nem számolja. Ha 
viszont a Ports sorra kattintunk, láthatjuk, milyen portok ak- 
tívak (rendezzük sorba ezeket is állapot szerint). Itt rögtön 
látszik az is, hogy PPTP vagy L2TP kapcsolatot sikerült kiépí- 
teni. Az LZTP kapcsolat előfeltételei és megoldásai pontosan 
megegyeznek a korábban leírtakkal. 


Ne working with windows / 2002. 10. 
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Csatlakozási probléma tartományi fió- 
kok esetén 

A legjobb szakemberekkel is megesik 
néha, hogy átsiklanak egy-egy, szinte 
minden oldalon hangsúlyozott sza- 
bály felett. Ha az RRAS telepítése 
után a csatornák felépítése nem sike- 
rül, mégpedig az eseménynapló sze- 
rint azért, mert ,a hitelesítő kiszolgáló nem elérhető..." — 
nos akkor első dolgunk legyen ellenőrizni, hogy az RRAS ki- 
szolgáló tagja-e az Active Directory-ban található RAS and 
IAS Servers csoportnak. 








KEST AE It ei 





[Ő ce TT EENYETETTETEETTTTETTSEEENKEEETET 
I] Aetion  Vew (] General Members ] Member Of] Managed By] 
Tree] 


Members: 
Name —— ] Active Directory Foldet — 












Active Directory Us 















E Ej) falatrax.hu ő § See 
CI Bulin EJSERVER falatrax hu/Domain Controllers 
83 E camasters 
Big Domain Cor. 1 
a — Foreignseci sa Kkt fáldkésdési ] 
(EJSERVER falatrax hu/Domain Controllers 
S) w2KPRO Talatrax hu/Computeis 
IEJMEMBERSRV  falatrax hu/Computers 
Administtator alatrax hu/U sers 
€2 Guest falatrax hu/tU sets 
£2 TslntemetUser —— falattax hu/Users 
2 IUSR. FALATRAX . falatrax hu/Users 
7 [ec Type names separated by semicolons or choose from ís) 
[ETET — 








E 





Id Az RRAS kiszolgálót fel kell vennünk a tartományi , RAS 
and IAS Servers" csoportba 


A statikus útvonal felvétele 

Már csak egy dolog maradt hátra: megmagyarázni az RRAS- 
nak, hogy a távoli alhálózatokon milyen címtartomány talál- 
ható, illetve azt, hogy ha ide szeretnénk csomagokat külde- 
ni, akkor előtte fel kell építeni a VPN kapcsolatot, majd 
azon továbbítani az adatokat. Ezt statikus útválasztási útvo- 
nal (static route) létrehozásával tehetjük meg. Emlékezzünk: 
a központi alhálózat címtartománya 10.1.1.x, a vidékié pe- 
dig 10.2.2.x. Mindkét kiszolgálón az ,ellentétes" címtarto- 
mányhoz kell majd hozzárendelnünk az előzőleg létreho- 
zott demand-dial kapcsolatot. Az RRAS konzol ,IP routing / 
Static Routes" során válasszuk a ,New Static Route..." pa- 


rancsot. 




















Routng and Remote Access 
J Server Status. 
7 ED MEMBERSRV (local) 
HÉ Rorting interfaces 
Ports 
Remote Access Ckents (0) 











83 (I Remote Access Logging 






FF. Use thiz route to indiate damand dal connection: 





CI evet ] 














Id Kóbe vésett útvonal: a 10.7.7.x bizony a központi router 
felé keresendő 
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Itt válasszuk ki a VPN interfészt, a Destination mezőbe írjuk be 
a távoli alhálózat hálózatazonosítóját és alhálózati maszkját, 
valamint hagyjuk bekapcsolva a ,Use this rule to initiate 
demand-dial connections" opciót. Így az RRAS kiszolgáló, 
amikor a távoli hálózatba tartó csomagot észlel, felépíti a kap- 
csolatot és továbbítja — alagútban, titkosítva — az adatokat. 
Ugyanezt a beállítást persze meg kell tennünk a másik kiszol- 
gálón is. 


A puding próbája ... a ping 

Ezután már csak a puding próbája, a ping van hátra. Ha a 
VPN interfész épp aktív lenne, kapcsoljuk le, majd nyissunk 
egy parancssori ablakot és próbáljunk megpingelni egy ,tá- 
voli" IP címet. 








De! 
sztinat don hozt unreachab; 
fReguest tíned out. 
feguest tíned out. 

guest tined out. 
fReguest tined out 

guest tined out 





Id A ping aktiválja a VPN-t... győztünk! 


Míg a VPN kapcsolat inaktív, , Destination host unreachable" 
üzenetet kapunk, viszont ezalatt az RRAS elkezdi a kapcsolat 
felépítését (, Connecting... "). Ahogy a kapcsolat felépült, némi 
gondolkodás után a válaszok is visszaérkeznek: győztünk. 


Következő számunkban a DNS, WINS és egyéb címzési mizé- 
riáknak, finomságoknak nézünk utána, valamint szó esik majd 
a RADIUS kiszolgálókról is. Addig is, jó alagutazást! 
folytatjuk... 


Fülöp Miklós 
mickOnetacademia.net 
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Digital Money 


Az elektronikus kereskedelemről és az elektronikus aláírásról szóló törvények megterem- 
tették Magyarországon is a jogszabályi hátterét annak, hogy az Interneten keresztül áruk, 


illetőleg szolgáltatások cseréljenek egymással gazdát, vagyis végre meginduljon az elektro- 


nikus kereskedelem. 


Mint a való térben, a virtuális világban is az áruért, vagy szolgál- 
tatásért ellenszolgáltatás jár cserébe, vagyis az esetek nagy több- 
ségében pénz. Az ellenérték elektronikus úton való teljesítése 
során a leggyakoribb félelem a biztonság hiánya, az hogy sze- 
mélyes adatainkhoz hozzáférve bankszámlánk terhére illetékte- 
len kifizetések is teljesíthetők. Bebizonyosodott, hogy a hitelkár- 
tya nem ideális megoldás az Interneten keresztül történő kifize- 
tésekre. Technikai megoldásként a piac a digitális pénz megal- 
kotásával reagált. A digitális pénz egy bitsorozat, pénzhelyette- 
sítő fizetési eszköz, amely ellenérték fejében vásárolható a kibo- 
csátótól, és a számítógép merevlemezén, elektronikus pénztár- 
cában vagy chipkártyán tárolható. 


A digitális pénzen alapuló leegyszerűsített fizetési modell a kö- 

vetkezőképp alakul: 

1. az ügyfél átutal a bankszámláról 300.000.-Ft-ot a digitális 
pénz kibocsátójának számlájára, 

2. a kibocsátó a megfelelő virtuális forintösszeget jóváírja az 
ügyfélnek, 

3. a 300.000.-Ft mindaddig a kibocsátó számláján marad, amíg 
valaki, akihez a virtuális forintok kerültek azt be nem váltja, 

4. az ügyfél kifizetéseket teljesít a digitális pénzzel, 

5. a kereskedő a megkapott összeget visszaküldheti a kibocsá- 
tónak és átalakíttathatja igazi pénzzé, vagy kifizetéseket esz- 
közölhet vele további kereskedők felé, 

6. a digitális pénz egyedi sorszámmal van ellátva, melynek cél- 
ja a többszörös felhasználás, és egyéb csalások kiküszöbölé- 
se. A felhasználó pénzügyi szokásai, így a pénz nyomon kö- 
vethetőségének elkerülése végett a vak aláírás (blind signa- 
ture) módszerét alkalmazzák. Ezt a protokollt akkor használ- 
juk, ha a másik féllel nem akarjuk közölni, hogy mit ír alá. Ez 
jelen esetben azért jelent problémát, mert a banknak a 
pénzt hitelesítenie kell anélkül, hogy ismerné a pénz sorszá- 
mát. 

7. az átváltás azt jelenti, hogy a kibocsátó leveszi a virtuális fo- 
rintnak megfelelő összeget az ügyfél számlájáról, és átutalja 
a beváltást kérőnek. Profit termelésre akkor van lehetőség, 
ha a valódi pénz befizetése és kifizetése közti időtartamra be 
tudta fektetni ezt az összeget. 

A digitális pénzhez kapcsolódóan több nagy projekt van folyamat- 

ban, melyek főként az Interneten való fizetéshez kapcsolódó 

problémákat igyekeznek megoldani. Ha a digitális pénz tényleg 

domináns szereplőjévé válik az Internetes piacnak, akkor fontos a 

megfelelő szabályozás kialakítása. Kérdés, hogy a jogszabályoknak 

vagy az önszabályozásnak kell nagyobb teret engedni ezen a terü- 
leten, annyi viszont bizonyos, hogy elengedhetetlen egy technoló- 
giafüggetlen szabályrendszer kialakítása. 


Európai Unió 

Jelenleg az Európai Unión belül a 2000/46/EC irányelv szabá- 
lyozza az elektronikus pénz kibocsátásának kérdéskörét. Az 1. 
Cikkely értelmében az elektronikus pénz olyan pénzhelyettesí- 
tő eszköz, amelyet elektronikus úton, mint például a chip kár- 
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tyán vagy számítógép memóriában tárolnak, és általában korlá- 
tozott összegű kifizetések teljesítésére szolgál. 


Kibocsátására — a magyar szabályozástól eltérően — nem csak hi- 
telintézetek jogosultak, hanem olyan jogi személyek is, amelyek 
megfelelnek az irányelvben részletezett szigorú követelmények- 
nek. Ilyen például az induló tőke 1 millió EURO-ban történő 
meghatározása, illetve az az előírás, hogy a működés során a tő- 
ke nem csökkenhet az irányelvben meghatározott szint alá. A 
társaságnak csak meghatározott feltételek mellett lehet részese- 
dése más társaságokban, és az elektronikus pénz kibocsátásán 
kívül is csak az irányelvben meghatározott más tevékenységeket 
végezheti, mint például adattárolás, elektronikus pénz kezelése. 
Az irányelv kimondja a digitális pénz visszaváltásának kötele- 
zettségét, és azt, hogy a felek közti szerződésben ennek módját 
szabályozni kell. Lehetőséget ad a kibocsátónak egy visszaváltá- 
si minimumérték meghatározására, amely azonban nem halad- 
hatja meg a 10 eurót. 

Az elektronikus pénzhez kapcsolódóan az Európai Unió szabá- 

lyozása elvárásokat, ajánlásokat fogalmaz meg a kibocsátó és a 

felhasználó közötti szerződések tartalmi elemei tekintetében is. 

A tárgykörben már 1997-ben kiadott ajánlás két csoportra oszt- 

ja az elektronikus fizetési eszközöket: 

s a távolról hozzáférést biztosító fizetési eszköz az ügyfél szá- 
mára lehetővé teszi, hogy a kártyával a pénzintézetnél elhe- 
lyezett számlája terhére — a biztonsági kódok megfelelő 
használata mellett - meghatározott pénzügyi műveletet vé- 
gezzen; 

s az elektronikus pénzeszköz olyan újratölthető kártya vagy szá- 
mítógép-memória, amelyen értékegységek elektronikus úton 
tárolhatók, lehetővé téve használója számára a fizetést. 

Ezen kívül - a tranzakciók feltételeinek áttekinthetőségét előtér- 
be helyezve - szabályozza a felek közötti szerződés tartalmi ele- 
meit, valamint részletezi a kibocsátó és a felhasználó felelőssé- 
gét és kötelezettségeit. Emellett az elektronikus fizetési eszköz 
elvesztése esetén bejelentési kötelezettséget ír elő, illetve a szer- 
ződő felek közti alternatív vitarendezési lehetőségek megte- 
remtéséről szól. 


Magyarország 

Az Uniós szabályozással összhangban Magyarországon a pénz- 
forgalomról, a pénzforgalmi szolgáltatásokról és az elektronikus 
fizetési eszközökről szóló 232/2001. (XII.10.) Kormányrendelet 
szabályozza ezt a kérdéskört. 

Magyarországon a digitális pénz jogszabályi alapjait megteremtet- 
ték, bár az uniós szabályozással ellentétben csak a hitelintézetek 
kapnak lehetőséget digitális pénz kibocsátására, amin érdemes 
lenne változtatni, a digitális fizetések valódi gyakorlati alkalmazá- 
sának minél szélesebb körben való lehetővé tétele érdekében. 


Dr. Illés Blanka 
Nádas 8. Mayer Ügyvédi Iroda 
mayer(Onadas-mayer.hu 
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Microsoft 


Exchange 2000 


Nyilvános mappák 


Az Exchange 2000-ben a nyilvános mappák területén fontos változtatások történtek. Az Exchange és az 
Active Directory összefonódásaként a jogosultságok kiosztása, és használata módosult. Ahogy az adatok 
elérése is sokféle módon történhet, a jogosultságok állítása is bonyolultabb. Miután megismerkedtünk 
kicsit a nyilvános mappákkal, belevetjük magunkat a jogosultságok dzsungelébe. 


A nyilvános mappák rugalmas keretet nyújtanak a csoportos 
munkavégzéshez. Nem csak leveleket, de névjegyeket, felada- 
tokat, gyakorlatilag bármilyen állományt tárolhatunk a nyilvá- 
nos mappákban, ez teszi őket univerzálissá. A postaládákat 
tartalmazó adatbázissal ellentétben a nyilvános mappák tartal- 
mát már alapértelmezésben is mindenki olvashatja, sőt a map- 
pákban írás joga is van mindenkinek. A nyilvános mappáknak 
éppúgy lehet e-mail címe, mint a felhasználóknak, vagy cso- 
portoknak; lehet nyilvános mappák nevében levelet is írni. 
A legegyszerűbb Exchange 2000 is képes több nyilvános map- 
pákat tartalmazó adatbázist kezelni, azonban ezek az adatbá- 
zisok nem egyenrangúak, mert csupán a telepítésnél létreho- 
zott nyilvános mappákat tartalmazó adatbázis érhető el 
Outlookból MAPI protokollon keresztül. Ezenkívül ez az első 
nyilvános mappa-struktúra az egész szervezet szintjén azonos! 
(Ne feledjük, egy Active Directory erdőben egy Exchange szer- 
vezet (Organization) létezhet.) 
A nyilvános mappákat számos protokollon keresztül érhetjük 
el: 
5  MAPI-val Outlookból — csak a telepítésnél létrejött nyilvá- 
nos mappákat érhetjük el vele! 
s HTTP-n keresztül Internet-böngészővel — URL címzéssel 
s Közvetlenül a fájlrendszerből — mint egy hálózaton megosz- 
tott könyvtár tartalmát láthatjuk, használhatjuk. Az alkalma- 
zásokból megnyithatjuk a nyilvános mappákban tárolt do- 
kumentumokat, közvetlenül menthetjük is őket — mindezt 
az EXIFS teszi lehetővé. 
A nyilvános mappák tartalmát lehet szinkronizálni más szerve- 
zetben, vagy azon kívül eső Exchange kiszolgálókra is, így több 
telephely esetén is könnyedén megoszthatunk információt. 


Nyilvános mappa adatbázisok és mappa-struktúrák 

A nyilvános mappákat is adatbázisban tárolja az Exchange, 
csakúgy, mint a postaládákat. Minden nyilvános mappákat 
tartalmazó adatbázishoz tartozik egy mappa-hierarchia 
(Folder Tree), amely az adatbázisban levő hierarchiát repre- 
zentálja. Az adatbázisok és a mappa-hierarchiák szorosan 
összefüggnek. Egy adatbázishoz pontosan egy mappa-hie- 
rarchia tartozik, míg egy mappa-hierarchia tartozhat külön- 
böző Exchange kiszolgálókon levő nyilvános mappa adatbá- 
zishoz is! 


Kétféle mappa-hierarchia létezik az Exchange 2000-ben. A 
telepítéskor létrejövő nyilvános mappa adatbázishoz - a 


,Public Folder Store-hoz" — tartozó , All Public Folders" hie- 
rarchia például - ha akarjuk, ha nem — a szervezet összes 
Exchange kiszolgálóján azonos. Mit jelent ez? A szervezetben 
bárhol vagyunk is, az Outlookban a nyilvános mappák hierar- 
chiája azonos lesz. Persze a jogosultságok beállításával elbúj- 
tathatók bizonyos mappák, nem kell feltétlenül látnia min- 
denkinek mindent. Az Exchange System Managerből tudjuk 
megnézni, hogy melyik hierarchia melyik kiszolgálón levő 
adatbázishoz tartozik. 


KAZE azt a 2 


General ] Detais ] Security ] 


(I 
a Public Folders ! 








Folder tree type: 
MAPI clientg I 


Public stores associated to the folder tree: 


LONDON ! 


Public Folder Store LONDON) Egyetlen ! 


a 
! 

töJB B 
Id Az elsőként létrejött nyilvános mappa adatbázisának tí- 
Pusa is azt sejtett, hogy Outlookból való használatra szán- 
ták 


A telepítés után létrehozott nyilvános mappa adatbázisokat 
nem láthatjuk az Outlookból. 
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General ] Detals ) Security ] 


(Ir 
a] 
a Group 





] Folder tree type: 


! fFenerat purpose 


"Public stores associated to the folder tree: 





[Name [storage Group ÍServe  ] 


Group Egyetlen LONDON 


B Általános célú nyilvános mappa hierarchia és a hozzá 
kapcsolódó adatbázis 
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A pluszban létrehozott adatbázisok tartalma HTTP-n ke- 
resztül, a fájlrendszerből, megosztott könyvtárként és 
NNTP kliens használatával érhető el. Míg a MAPI típusú hi- 
erarchia az Exchange szervezet minden kiszolgálóján azo- 
nos, addig a pluszban létrehozottak csupán azon a kiszol- 
gálón léteznek, ahol létrehozunk, illetve ahová mi magunk 
replikáljuk őket. 


Vegyük sorra, hányféleképpen hozhatunk létre nyilvános 
mappákat.Talán a legegyszerűbb, leggyakrabban használt 
módszer, amikor az Outlookból hozunk létre nyilvános 
mappát. A képen látható, hogy nem csupán leveleket rakha- 
tunk egy nyilvános mappába, hanem létrehozhatunk közös 
naptárat (Appointment Items), vagy közös névjegytárat 
(Contact Items) is, de feladatokat (Task Items) tartalmazó 
mappákat is. 


VAI Public Folders - Microsoft Outfook e ge -lol2d 
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Nyilvános mappa létrehozása Outlookkal 


Ugyancsak bármilyen típusú mappát létre tudunk hozni 
HTTP-n keresztül is: 
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Id Mappa létrehozása a fájlkezelóból 

Ebben az esetben azonban csak levéltípusú (Mail Items) map- 
pát tudunk létrehozni, és mindent úgy látunk, mintha könyv- 
tár és fájl lenne. Egész viccesen tud kinézni egy névjegy, vagy 
egy naptárbejegyzés, ha fájlkezelőből nézzük! 

Megjegyzés! Ha az utóbbi módon rakunk be valamit (mond- 
juk egy ártatlan dokumentumot) egy mappába, majd ugyan- 
azt a mappát megnyitjuk Outlookkal, azt tapasztalhatjuk, 
hogy nincs feladója (üres a From mező) az állománynak. 
Létrehozni ugyan sokféleképpen lehet nyilvános mappát, a 
belső tulajdonságait állítani már csak Outlookból lehet, kivéve 
a hozzáférési jogosultságokat, amelyeket a fájlkezelőből is ál- 
líthatunk, de nem mindig szabad állítanunk! 


Az Exchange előző verziójához képest — ahol nyilvános map- 
pát létrehozni kizárólag Outlookból lehetett — láthattuk, hány- 
féle módon tudjuk a nyilvános mappákat létrehozni, kezelni. 
Az előbbi módszerekkel bármely felhasználó, a megfelelő tu- 
dás és jogosultság birtokában képes létrehozni nyilvános map- 
pát. A rendszergazdáknak van még egy lehetőségük, ahonnan 
létre tudnak hozni nyilvános mappát. Ez pedig az Exchange 
System Manager. 

















Celeted teme 
Drafts 
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kid Nyilvános mappa létrehozása HTTP-n keresztül 


Az alábbi képen látható, hogy létre tudunk hozni újabb map- 
pát, mintha azt egy fájlkiszolgálón tennénk. 
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(Creates a new object ín this container. 
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Id Nyilvános mappa létrehozása System Managerból 


Miután ennyi helyről létrehoztunk mappákat, érdemes lenne 
megnézni, mit is lehet beállítani egy-egy mappával kapcsola- 
tosan. 

Válasszuk szét a felhasználói és refidszétgasdái szintet! 

Ha az adott mappa tulajdonosa nem maga a felhasználó, 
csak tájékozódhat a beállításokról — például a mappa mére- 
téről, a jogosultságokról. 

Aki létrehozza a nyilvános mappát, az lesz a tulajdonosa. 
Ha ez egy egyszerű felhasználó a megfelelő jogosultságok- 
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kal, ő csaknem bármit megtehet a mappá- 
val. Jogosultságokat állíthat, szabályozhat- 
ja a mappa tartalmát moderátorok segít- 
ségével, űrlapokat rendelhet a mappához, 
szabályokat hozhat létre a mappába érke- 
ző dokumentumokra vonatkozóan. 

A rendszergazda sokkal több mappabeál- 
lítást tud szabályozni. Például a mappák replikációját más 
kiszolgálókra, vagy az e-mail cím beállításokat. Nézzük meg 
ezeket közelebbről! — 





(EZTTTEZT TETT ENNNENEEEEEETEKETETTTT 212 
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e Group 
Path 
[7Attsóst Élet homo — 
G Same as folder name 
1 C Usgthis name: 
! ÍS véte NM TET ed] 
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Id Nyilvános mappák tulajdonságlapjai System Mana- 
gerbóől nézve 


A Replication lapon állítható minden, ami a nyilvános map- 
pa kiszolgálók közti szinkronizálást érinti. Később részlete- 
sen foglalkozunk majd vele. 

A Limits lapon szabályozható a mappa mérete, valamint le- 
hetőségünk van felülbírálni két beállítást, amik egyébként az 
adatbázis tulajdonságlapjai közt állíthatók. Az egyik, hogy 
mennyi ideig tartsa meg a mappából törölt elemeket a ki- 
szolgáló. A másik pedig az , Age limit", az állományok maxi- 
mális idejét határozza meg. A beállított idő letelte után a fáj- 
lok automatikusan törlődnek a mappából. 

Az Exchange General lapon található Delivery Options 
gomb mögött állítható, hogy ki tudjon levelet küldeni a nyil- 
vános mappa nevében. 

Az Exchange Advanced tulajdonságlapon lehet beállítani, 
hogy az e-mail címmel rendelkező nyilvános mappák lát- 
szódjanak-e a címlistában, vagy sem. 

A Permissions lap a jogosultságok beállításait takarja, amiről 
hamarosan bővebben lesz szó. 

A System Managerből szabályozható, hogy mely mappáknak 
legyen e-mail címe. Attól függően, hogy az Exchange mixed 
vagy natív módban van (Figyelem: nem a Windows 2000 
mixed módjáról van szó, hanem az Exchange 2000-ről!), a 
nyilvános mappák e-mail címkiosztása eltérően működik. 
Ha az Exchange mixed módban van, az első nyilvános map- 
pa adatbázisban (Default Public Store) létrehozott mappák 
automatikusan e-mail címmel ellátottak lesznek, nem is le- 
het elvenni az e-mail címet, de ilyenkor alapértelmezésben 
a nyilvános mappák nem látszódnak a címlistákban. 
Exchange mixed módban, ha a nyilvános mappa adatbázist 
utólag hoztuk létre, az abban létrehozott nyilvános mappák- 
hoz nem keletkezik automatikusan e-mail cím. 

Ha az Exchange natív módban van, a nyilvános mappáknak 
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csak akkor képződik e-mail címe, ha a rendszergazda ezt külön 
beállítja. Az e-mail cím automatikusan bekerül a címlistába is. 
A nyilvános mappákhoz e-mail címet létrehozni a System 
Managerből lehet, ahogy az alábbi képen is látszik. 
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Id £-mail cím létrehozása nyilvános mappához 


A ,Mail Enable"-t választva a menüből, létrejön az Active 
Directoryban egy objektum a nyilvános mappához. Az 
összes nyilvános mappához tartozó AD objektum az Active 
Directory Users and Computers MMC konzolban a Micro- 
soft Exchange System Objects konténerben látható. 


Jogosultságok 

A hozzáférési jogosultságokat több helyről, többféleképpen 
szabályozhatjuk. A nyilvános mappákhoz rendelt jogosultsá- 
gok tulajdonképp Windows 2000 jogosultságok, hisz az 
Exchange az Active Directoryra támaszkodik. A Windows 
2000 kezeli az Exchange-specifikus jogosultságokat is (például 
ki tud létrehozni a legmagasabb szinten nyilvános mappát. 


Jogosultságokat az Active Directoryban létező felhasználók- 
hoz, csoportokhoz rendelhetünk. Az Exchange-ben adott 
jogosultságok öröklődnek. Jogokat külön vagy egyben is ad- 
hatunk a mappákra és a bennük levő elemekre. 

A Nyilvános mappák tulajdonságlapjai közül a Permissions la- 
pon három nyomógombot találhatunk; mindegyik mögött más 
jogokat oszthatunk. A legfelső a Client Permissions gomb, a ha- 
tására feljövő ablakból szabályozható a kliensekről a mappa- 
hozzáférés. Az alábbi kép baloldalán látható az az ablak, ami 
ilyenkor feljön. Itt nem közvetlenül Windows 2000 jogosultsá- 
gokat látunk, hanem Exchange 

nyelvezetűt, ami volt már az 





Exchange korábbi verzióiban is. SSEL a 
füle ea ji Name: Role 
Különböző szerepekhez, kü- át 
2. zt ze a [Admiristta 0 ös 
lönböző előre csomagolt jogo-  fáommaz  Comtua 
Remoye 





sultságokat rendelhetünk egy- 
szerűen, gyorsan. A lenti képen 
egy mappa alapértelmezett jo- — . pemisions ez SZőB 


Bdlez [author . 





gosultságai — láthatóak. A 
,default"-hoz rendelt jogok tu- Pitt IT Földet önmer 
lajdonképp az Everyone cso- [7 Resdítems FT fidde 
portot jelenti. Ha a Client Per- CERES E ee 
missions gombra úgy kattin- € More C None 

6 Own 6 Own 
tunk, hogy közben nyomva Car C AL 
tartjuk a CTRL billentyűt, az ESSSsesSrsesessütt 
alábbi képen jobboldalon lát- tea 7) 
ható Windows 2000-es jogo- Ser E 
sultságosztó ablakot kapjuk. Mappatulajdonságok I. 





Permissions for Group. 


Folder rights ] 





telt 
£T2? ANONYMOUS LOGON 
€Z2 Everyone 


Permissions: 





Allow 
Delete a 
Read permissions u 
Change permissions a 
Take ownership OU 
Synchronize u 
List Contents o 





onunon 


le 


Addítional permissions are present but not 


Advanced. ]/ viewable here. Press Advanced to see them. 
(7. Allow inheritable permissions Írom parent to propagate to this 





EE] e] 


Id A mappajogosultságok — Client Permissions — két formája 
Amikor jogokat osztunk, az előre definiált szerepek szerint 
a kiosztott jogosultságok automatikusan Windows 2000 
s nyelvre fordítódnak". 

Figyelem! Egy MAPI-val használatos nyilvános mappa ese- 
tén tilos a Windows 2000 jogosultságokat közvetlenül állíta- 
ni! Megtehetjük, de csak egyszer, ugyanis ha közvetlen állí- 
tunk Windows 2000 jogosultságokat, az első alkalom után 
az ACL rögzül és elmozdulni róla nem egyszerű. 
Demonstrációként megváltoztattam egy MAPI-s nyilvános 
mappán a Windows 2000 jogosultságokat. Először minden 
figyelmeztetés nélkül hagyta is. Mikor újra próbálkoztam, a 
következő hibaüzenetet kaptam: 


MEZ XI 


EY 





Pemissi €9 Invalid window handle 


1D no: 80040102 
Roles Exchange System Manager 














[7 Creal ök 

[7 Reac 

[7 Create subfolders [7 Folder Visible. 
—Fditíteme——— e Delete items — 


Id Hibaüzenet jogosultságok változtatásakor 


A Microsoft tudásbázis 0270905-ös cikke pontosan erről az 
esetről, és a megoldásról szól. Jó bogarászást! 

Még mindig a nyilvános mappák Permissions tulajdonság- 
lapjánál tartunk, nézzük a második gombot. Ez a Directory 
Rights feliratú. Ha a nyilvános mappa nem rendelkezik e- 
mail címmel, ez a gomb szürke. E-mail címmel rendelkező 
nyilvános mappák esetén van csupán értelme, mert rákat- 
tintva állíthatók az adott mappához tartozó Active 
Directoryban tárolt objektumhoz rendelt jogosultságok. 

A harmadik gomb az Administrative Rights amely mögött a 
nyilvános mappákhoz rendelhető rendszergazdai jogosultsá- 
gok szabályozhatók, például hogy ki állíthatja a replikációt, 
vagy kvótákat ki szabályozhatja, ki változtathatja a mappához 
rendelt kliensoldali jogokat stb. Mindezek segítségével nagyon 
finoman szabályozható minden mappa és tartalmuk jogosult- 
sága. Van néhány speciális nyilvános mappákkal kapcsolatos 
jogosultság, amely a legmagasabb szintről öröklődik. Ilyenek a 


technet 


rendszergazdai jogosultságok, valamint az is, 
hogy ki tud a mappahierarchia gyökerében 
mappát létrehozni (pontosan a Create Top 


nyire az Organization szintről indulnak, az Ad- 

minisztratív csoporton (Administrative Group) 

át a nyilvános mappa hierarchián (Public Folder Tree) keresz- 
tül jutnak le a mappákhoz. 


A beállított jogosultságok automatikusan öröklődnek lefelé a 
struktúrában, azonban a mappák csak létrehozáskor öröklik 
a beállításokat a szülőtől, a későbbi változások már nem jut- 
nak le. Cserében nemcsak a jogosultságok, hanem egyéb 
beállítások is terjeszthetők a mappahierarchiákban. A tulaj- 
donságokat terjeszteni az adott mappán állva a menüből AlI 
tasks -Propagate Settings parancs segítségével lehet: 








] am úm [d 1BÍEL A REIXGBBIR 
iree] 1 (Connected to LONDON) 


Éj Nutraders (Exct SZÉK 


TIZET Tt 2] 


Select the property of this folder to apply to al sub-folders. 





IC Age imits 

JET Deleted ítem retenton time 
JÖT Foldet rights 

IC Keep per user resd/unread state 





E A mappákon örököltethető beállítások 


Csak néhány a sok közül: 

s Jogosultságok — A kliensoldali és a rendszergazdai jogok 
egyaránt örökíthetők 

s Replikációs beállítások 

e Kvóták — az élettartamra, a méretekre, és a törölt elemek- 
re vonatkozó beállítások 

e Active Directoryval kapcsolatos beállítások: látszódjon-e 
a címlistában, legyen-e e-mail címe stb. 


A következő részben a nyilvános mappák replikációjával is- 
merkedünk meg. 


Dorner Csilla 
dorner.csillagonetacademia.net 
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XMLgessünk 16. 


SOL XML 3.0 - I. rész 


Az SOL Server 2000 számos beépített XML- szolgáltatással rendelkezik, viszont a termék 

megjelenése óta több mint három év telt el, és az XML- technológiák pont az utóbbi idő- 
ben indultak szédületes fejlődésnek. Az SOL Server emiatt újabb és újabb XML- szolgáltatásokat kapott, 
melyeket külön csomagban lehet letölteni. Ez az SOLXML programcsomag. 


Nézzük meg miért jó nekünk e kiegészítés, mire tudjuk bevet- 
ni a mindennapi munkában? Az első részben a menedzselt 
SOLXML osztályok használatával foglalkozunk, a következő 
számban pedig az SOLXML Webszolgáltatásokat és a DataSet 
módosítások visszaírását vesszük górcső alá, egy komplett al- 
kalmazáspéldán keresztül. 


Előzmények 

Korábban (tech.net nem tudom mikori szám) már beszéltünk az 
SOLXML szolgáltatásokról, akkor a 2-es verziót alapul véve. Is- 
métlésképpen tekintsük át, milyen alapszolgáltatások laknak a 
programcsomagban. 


Az SOLXML programcsomag célja az SOL Server adatbázisai- 
ban, tábláiban tárolt relációs adatok elérése és manipulálása 
XML adatként. Azaz egy kétirányú interfészt definiálnak az SOL 
Server és az XML világ közé. 

Az átjárásnak többféle módját is létrehozták. Ezek egy része 
közvetlenül az SOL OLEDB providerben van megvalósítva, így 
közvetlenül is kommunikálhatunk XML adatokkal az SOL 
Server felé. 

Más esetben az adatbázisokat publikálhatunk az IIS segítségével 
is, így HTTP-n keresztül is elérhetők az adatbázisok. Ezzel a le- 
hetőséggel a hivatkozott SOLXML cikkben már foglalkoztam, 
így most nem fejtem ki bővebben. 


SOLXML menedzselt osztályok 

Ha .NET alkalmazásokból szeretnénk kihasználni az SOLXML 
szolgáltatásokat, akkor az SOLXML menedzselt osztályokat kell 
használnunk. 

Az osztályokat tartalmazó assembly az SOLXML telepítő [2] fut- 
tatása után a Global Assembly Cache-ben található, 
Microsoft.Data.SgIXml néven, 3.0.1523.0 verzióval. 

Fontos, hogy az XSD sémákkal kapcsolatos szolgáltatások helyes 
működéséhez az MSXML 4-et is fel kell telepíteni a gépre [3]. 
Az ADO.NET SOL osztályokhoz hasonlóan elnevezett főbb ob- 
jektumok a következők: SgIXkxmICommand, SglXmIParameter és 
SaglXmlAdapter. 

Az SglIXmICommand segítségével lehet végrehajtani XML kime- 
netű SOL parancsokat, tárolt eljárásokat, XML nézeteket és 
sablonokat (ez utóbbi kettőről a korábbi SOLXML cikkben ol- 
vashatnak). Azaz olyan mint az ADO.NET-es SglCommand, 
csak nem ,közönséges", hanem XML kimenetű parancsokra 
van specializálva. 

Az SglXmIParameter a parancsokhoz kapcsolódó paraméterek 
kezeléséhez fog segítséget nyújtani, teljesen analóg módon az 
SalParameter osztályhoz, csak ez XML sablonokhoz és nézetek- 
hez is tud paramétereket szállítani. 

Az SglXmlAdapter közönséges ADO.NET DataSet feltöltésére és 
a módosítások DiffGram formátumban történő visszatöltésére 
van kialakítva. 


A tesztelést egy webprojektben fogjuk végrehajtani (7. ábra), 
mert az XML kimeneteket Internet Explorerben lehet kényel- 
mesen elemezni. A kódokat a teszt weblapok Page Load ese- 
ménykezelőjében írjuk meg, azaz a lap elindulásakor generál- 
tatunk valamiféle kimenetet. 


TA Solution xmiI6 TI project) 
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"I Microsoft. Data. SalXrnl 
(2 System 
52 System.Data 
5 System.Drawing 
"I System. Web 
(I System. XML 
(EJ Assemblyinfo.cs 
4) Global.asax 
E] orders. aspx 
(Hi Web.config 


A teszt webprojekt re- 
! ferenciával a Microsoft.Da- 
ta.Xml assemblyre 


Nézzük meg az SglXmICommand inicializálását! 
string connString — 
€"Provider—SOLOLEDB; 

Server-(1ocal) ; 

Database-Northwind; £ 

Integrated Security-SSPI"; 
SalxmilCommand cmd - new SalxmlCommand(connsString) ; 
Valójában itt már le is bukott a menedzselt, .NET-es 
SglXmICommand . objektum, aki a COM-os SOLOLEDB 
providert használja, hisz a konstruktorban egy közönséges 
OLEDB connection stringet használ. Ha egy picit belenézünk 
az assembly belsejébe, nyilvánvalóvá válik, hogy a COM-os 
ADODB.Stream és egyéb objektumok köré írtak csomagoló- 
osztályokat, és ezek segítségével hívják meg az OLEDB XML 
szolgáltatásokat. Valószínűleg csak a következő SOL Server 
verzióban várható közvetlen menedzselt osztályokkal történő 
XML elérés. Sebaj, amíg működik a COM Interop ez csak esz- 
tétikai (és némi teljesítmény) probléma. 
A lekérdezések kimenete általában nem tartalmaz xml gyökér- 
elemet, hisz így könnyű egymás után fűzni több parancs kime- 
netét. Ha viszont egyetlen lekérdezés kimenetét kell feldol- 
gozni, célszerű kérni egy mesterséges gyökérelemet az adat- 
halmaz köré, így DOM és egyéb xml technológiákkal feldol- 
gozhatóvá válik az eredményhalmaz. A mesterséges gyökér- 
elem kijelölése nagyon egyszerű: 
cmd.RootTag - " orderlist"; 
Tesztpéldánkban egy nyomtatásra szánt riportot szeretnénk 
készíteni megrendelésekről és azok részletező tételeiről. 
ASP.NET Data bound vezérlőkkel (DataGrid és társaik) és User 
Controlokkal persze megoldható a dolog, de most egy alterna- 
tív, XML-XSLT alapú megoldást tekintünk át. Mindkettővel el- 
érhetjük ugyanazt a célt, de ha bonyolultabb programozott lo- 
gikára is szükség van, általában egyszerűbbek az ASP.NET-es 
megoldások, míg nem túl komplex és nem interaktív riportok 
esetén sokszor egyszerűbb az XML-XSLT páros használata. Kü- 
lönösen sok táblából JOIN-okkal összevadászott lekérdezések 
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esetén az XSLT-s feldolgozás sokkal egyszerűbb tud lenni. 
Kiindulásként egy XML kimenetű SOL parancsot fogunk vég- 
rehajtani, ebben benne lesz minden szükséges információ a ri- 


port elkészítéséhez: 
cmd .CommandTrype - SalxmliCommandrType.Sal; 
cmd. CommandText- e" 
SELECT [order] .OrderID, 

OrderDate, 

ProductName, 

detail.UnitPrice, 

Ouantity, 

Discount 
FROM 

(Order Details] detail 
INNER JOIN 

Orders [order] 
ON 

detail.OrderID - 
INNER JOIN 

Products product 
ON 

detail.ProductID - product.ProductID 
FOR XML AUTO 
mi 

; 
Response.ClearContent ( ) ; 
cmd. ExecuteToStream(Response.OutputStream) ; 


[order] .orderID 


Az XML kimenetű SOL parancsot az ExecuteToStream() metó- 
dussal hajtjuk végre. Ő a megadott System.IO.Stream 
példányba képes az XML kimenetet eljuttatni. A Respon- 
se.OutputStream az ASP.NET oldal kimeneti adatfolyama, 
amelybe többek között az ASP-ből is jól ismert Respon- 
se.Write() is ír. Az oldal kimenete egyelőre egy nyers XML 
adatfolyam: 


zlOl21 





A http://localhost/xml16/orders.aspst - Microsoft Internet! 





) Address (E) htto:/focalhostfamitójorders-asp eremmzto. Ez It ő ÉG 








Le 


c?xmi vet 
corderlis 








sionz"1.0" encodingztutf-g" ?s 





aproduct ProductName: 
cdetail UnitPricez"14 

c/product: 

zproduct ProductNamez"Singaporean Hokkien Fried Mee"- 
detail UnitPricez"9.8" Guantityz"10" Discountz"0" /2 

c/products 

eproduct ProductNamez"Mozzarella di Giovanni": 

cdetail UnitPricez"34.8" Ouantítyz"5" Discountz"0" /5 

/products 





Ouantítyz"12" Di 








zorder OrderID-"10249" OrderDates"1996-07-OSTOO:00:007- 
cproduct ProductNamez"Tofu" 
cdetail Wnitpricez"18.6 
c/products 
zproduct ProductNamez-"Manjimup Dried Apples"- 2 


(Ej Done JATE (BE Local intranet. 


yz"9" Discountz"0" /s 








Id AMI kimenetű lekérdezés a böngészóben 


Tegyük fel, hogy ezt az adatfolyamot nem akarjuk megfor- 
mázni, hanem így, ebben a formában akarjuk publikálni, 
mert például a számlázóprogramnak szüksége van a megren- 
delések adataira. Ha ez a program az Interneten keresztül 
kapcsolódik a rendszerünkhöz, igény lehet a titkosított elérés- 
re. Ennek legegyszerűbb módja, ha beállítjuk az SSL haszná- 
latát a webkiszolgálón, és https-en keresztül érjük el az 
orders.aspx-et. 

Másképp megközelítve saját titkosítást alkalmazhatunk az 
adatfolyamra. Na nem saját algoritmust, nem vagyunk sarlatá- 
nok, és nem hisszük a betűfelcserélős vagy xor-os módsze- 
rünkről, hogy megfejthetetlen. A .NET keretrendszer számos 
nagyon egyszerűen használható titkosítási módszert ismer. 
Esetünkben a két oldal ismeri egymást, így egy közönséges 
szimmetrikus titkosítás teljesen megfelelő lehet. Azért fontos, 
hogy ismerik egymást, mert így biztonságosan (pl. személyes 
találkozással, titkosított levélben :) megegyezhetnek a közösen 
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használt szimmetrikus kulcsban, amivel a 
titkosítás és a dekódolás is történik. 

Például Rijndael algoritmussal a következő- 
képpen titkosíthatjuk az xml kimenetünket 


(ordersenc.aspx): 

Stream xmlContent - cmd.ExecuteStream( ) ; 

//Csak az első 16 karaktert használjuk, 

//ez a maximális kulcshossz a Rijndaelnél. 

string keyText - "Ez lesz a titkos kulcs"; 

string ivText - "Indulási vektor érték"; 

//Fontos, hogy az encoding minden karaktert 

//pontosan egy bájtra képezzen le. 

Encoding en - Encoding.GetEncoding("ISO-8859-2"); 

byte[] key; byte[] iv; 

key - en.GetBytes(keyText.Substring(0, 16)); 

iv - en.GetBytes(ivText.Substring(0, 16)); 

//Rijndael algoritmust használunk 

RijndaelManaged Crypto - new RijndaelManaged( ) ; 

//Ez a titkosító objektum 

ICryptoTransform tr - 

b crypto.CreateEncryptor(keyv, iv); 

//Amit benyomunk az origStream-be, az kijön 

//titkosítva a Response.OutputStream-be. 

CryptoStream origStream - 
new CryptoStream(Response.OutputStream, 

tr, CryptoStreamMode.Write); 

int buffSize - 8192; 

byte[(] buff - new bytelbuffSizelj; 

int readed; 

while ((readed - 

4 xmliContent.Read(buff, 0, buffSize)) 
//Átvödrözzük az xml tartalmat. 
origStream.Write(buff, 0, readed); 

) 

origStream.Close() ; 


ai 


mt] 


íz 0) ( 


Láthatóan most az SglXmICommand.ExecuteStream() metó- 
dust használtam, mert egy új Streamre volt szükség a feldolgo- 
záshoz. A kimenet nem embernek való csúnya, titkosított bájt- 
halmaz. 

A fogadóoldali alkalmazásnak ismerni kell a kulcsot (key) és az 
Initialization Vector (iv) értékét, hogy ki tudja bontani a kapott 
tartalmat. 

Tegyük fel, hogy a fogadó egy konzolalkalmazás, amely szeret- 
né letölteni és kicsomagolni a tartalmat. A feldolgozás egy le- 


hetséges módja látható az következő kódblokkban. 
string uri - 

4 "http://localhost/xml16/ordersenc.aspx" ; 
HttpWebReguest reg - 

4 (HttpWebReguest) WebReguest.Create(uri) ; 
//A belépett felhasználó nevében 
//történik a hozzáférés 

reg.Credentials - 

4 credentialCache.DefaultCredentials; 
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reg.Method - "GET"; //HTTP metódus 
WebResponse resp - reg.GetResponse(); 
Stream xmlEncrypted - resp.GetResponseStream( ) ; 
int readed; int buffLen - 8192; 
byte[(] buff - new bytelbuffLen] ; 
//HACK HACK HACK 
MemoryStream ms - new 
MemoryStream( ) ; 
while ((readed - 
B xmlEncrypted.Read(buff, O,buffLen)) 3 0) ( 
ms.Write(buff, 0, readed) ; 
) 
ms.Position - 0; 
string keyText - "Ez lesz a titkos kulcs"; 
string ivText - "Indulási vektor érték"; 
Encoding en - Encoding.GetEncoding("ISO-8859-2"); 
byte[] key; byte[] iv; . 
key - en.GetBytes(keyText.Substring(0, 8)); 
iv - en.GetBytes(ivText.Substring(0, 8)); 
RijndaelManaged crypto - new RijndaelManaged( ) ; 
ICryptoTransform tr - 
bt erypto.CreateDecryptor(key, iv); 
CryptoStream decrStream -— 
new CryptoStreamí(ms, 
tr, CryptoStreamMode.Read) ; 
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StreamReader reader - new StreamReader (decrStream) ; 
Console.WriteLine (reader . ReadToEnd ( ) ) ; 
reader.Close(); 

xmlEncrypted.Close() ; 

decrStream.Close() ; 

resp.Close() ; 


A titkosított Stream feldolgozása nem teljesen fájdalommen- 
tes. Elvileg az xmlEncrypted NetworkStream közvetlenül bele- 


irányítható a CryptoStream konstruktorba, azaz az 
CryptoStream decrStream - 

new CryptoStream (ms, 

tr, CryptoStreamMode.Read) ; 


sor helyett elvileg lehetne használni az 
CryptoStream decrStream -— 
new CryptoStream(xmlEncrypted, 
tr, CryptoStreamMode.Read) ; 


sort. A valóságban azonban egy Exception emelkedik fel, 
mintha túlolvasna a CryptoStream a forrás Streamen. Ez a hi- 
ba leginkább akkor jelentkezik, ha a forrásweboldal és a letöl- 
tőalkalmazás ugyanazon a gépen helyezkedik el. 

Tankó Péter barátom vette a fáradságot és kinyomozta, hogy 
a probléma oka az, hogy az ASP.NET vagy az IIS nem jól for- 
mázza meg az elküldött tartalmat. A titkosított tartalom 
Chunked Transfer Encoding [4] kódolással jut el az ügyfélprog- 
ramhoz, amelyben a kiszolgáló a hosszú tartalmat darabjaira 
vágja, és a darabokat megjelöli hossz és egyéb termináló ka- 
rakterekkel. Sajnos azonban az utolsó darab lezáró karaktere- 
it elhagyja. Az ügyfélprogram - a kiszolgálóval ellentétben - jól 
ismeri a HTTP szabványt, és keresi a lezáró karaktereket, ezért 
olvas túl a forrás NetworkStreamen. 

A probléma megkerülésére a HACK részben a letöltött Stream 
tartalmát először áttöltöttem egy MemoryStreambe, majd az 
dekódoltam. Így már hibamentes lett a dekódolás: 





Ed Az ügyfélprogram kimenete a dekódolt xm!I adatfolyam- 
mal 


Egy ennél elegánsabb megoldás arra épít, hogy a HTTP 1.0 
szabványban még nem létezett a Chunked Transfer Encoding, 
így ha az ügyfélnek megmondjuk, hogy HTTP1.O protokollal 
kérje le a kiszolgálótól a tartalmat, a kiszolgáló nem fog 
Chunked Transfer Encodingot használni, így nincs módja a hi- 
bát elkövetni. Ehhez csak egy sorral kell bővíteni az ügyfelet a 
kapcsolatfelvétel előtt: 

reg.ProtocolVersion - HttpVersion.Versionl0; 

Talán a példából látszik, a kézi titkosítás nem teljesen triviális, 
valamint a kulcs értéke bele van kódolva az alkalmazásba, így 
nagyon könnyen kinyerhető. Például az Anakrino nevű Cs 
decompilerben így néz ki a kulcsok értékadása a 


szamlazo.exe-ből visszafejtve (eh :): 
local8 - "Ez lesz a titkos kulcs"; 
1local9 - "Indulási vektor érték"; 


Emiatt ha a követelmények megengedik, sokkal egyszerűbb az 
SSL beállítása az IIS-en, mint a kézi titkosítás. Ott a nyilvános 
kulcsú titkosításon alapuló kulcscsere-algoritmus leveszi a vál- 
lunkról kulcselosztás problémáját, és gyakorlatilag nulla kódo- 
lással érünk célt. 


Formázott kimenetek előállítása 
Ha helyben, a webkiszolgálón szeretnénk feldolgozni a kapott 
XML tartalmat, az egyik legkézenfekvőbb lehetőség az XSLT- 
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vel történő transzformáció. Olyannyira, hogy az 
SglXmICommand objektumnak eleve készítettek egy XslPath 
jellemzőt. Ebben meg kell adni egy XSLT fájl elérési útját, 
amelyet az SgIXmICommand az xml kimenetre alkalmaz: 


cmd.XslPath - Server.MapPath("ord.xslt"); 
cmd.ExecuteToStream(Response.OutputStream) ; 


A korábbi xml kimenethez például az alábbi XSLT-t használ- 


hatnánk (ordersformatted.aspx): 
c?xml version-"1.0" encoding-"UTF-8" ?n 
cxs1l:stylesheet version-"1.0" 


xmlns:xs1-"http: / /www.w3 .org/1999/XSL/Transform"5 
cxsl:output omit-xml-declaration-"yes" /5 
cxs1l:template match-"/"5 
chtml: 
chead: 
ctitlesMegrendelések listájac/titles 
clink rel-"stylesheet" type-"text/css" 


§ href-"css/orders.css" /5 
c/headz 
ctable class-"list": 
cetr: 
ctdz 
cxsl:apply-templates 
b select-"orderlist/order"5 


cxsl:sort select-"GOrderDate" /5 
c/xs1l:apply-templatesz 
c/tdas 
ce/tr: 
c/tablez 
c/htmlz 
c/xs1l:templates 
cxs1l:template match-"order"5 
ctable class-"order" width-"100$"75 
ctr class-"orderheaderrow": 
ctdsSorszám: 
cxs1l:value-of select-"8OrderID" /5c/td: 
ctdoDátum: 
cxs1l:value-of select-"translate(substring- 
4 before(gorderDate, "T"), "-", !.")" /25.c/tdz 
c/tr: 
etr: 
ctd colspan-"2"5 
ctable class-"product"5 
cxs1l:apply-templates select-"product"5 
cxsl:sort select-"€ProductName" /5 
c/xs1l:apply-templatesz 
c/tables 
c/tdz 
ce/tr: 
c/tables 
£/xs1l:templates 
cxs1l:template match-"product"5 
ctr class-"prodrow"5 
ctd class-"prodnamecell": 
cxs1l:value-of select-"EProductName" /5 
c/tas 
ctdscxs1l:value-of 
§ select-"detail/eOuantity"/5 db, c/tds 
ctd:cxs1l:value-of 
select-"detail/eUnitPrice"/5 $/dbc/tds 
c/tr5 
c/xs1l:templates 
4£/xs1l:stylesheet: 


A némi költői túlzással pofásnak is mondható eredmény. 

Példánkban az XML kimenetet maga az SOL Server állította 
elő, az OLEDB provider csak fogadja és átadja nekünk. Ez azt 
jelenti, hogy a kacsacsőrök vígan repülnek át az SOL Server és 
az IIS között a hálózaton. Nos, ez nem egy világbajnok haté- 
konyságú feldolgozás. Ennél sokkal hatékonyabb tud lenni, ha 
az SOL Server az eredményhalmazt a maga tömör, bináris for- 
mátumában adja vissza, és az OLEDB provider alakítja azt át 
xml-lé. E módszer előnye, hogy átadja a terhelés egy részét az 
SOL Serverről a webkiszolgálóra, illetve csökkenti a két réteg 
közötti hálózati forgalmat. Ennek ellenére a módszer visszaüt- 
het, mert egy többszörös JOIN kimente SOL eredményhalmaz- 
ként olyan redundáns, annyi ismétlődő adatot tartalmaz, hogy 
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még az is lehet, hogy a FOR XML AUTO szószátyár kimenete 
is tömörebb lesz. Tehát nem csodafegyver az OLEDB 
providerre taksált xml konverzió, de érdemes megnézni a mi- 
kéntjét. Ismét központi objektumunk, az SglXmICommand egy 
újabb paramétere segít: 

cmd.ClientSidexml - true; 

Esetünkben a Client szó a webkiszolgálón futó ASP.NET la- 
punkra utal. A kívánt hatás eléréséhez az SOL parancsunkat is 
módosítani kell. A lekérdezés végén a FOR XML AUTO zára- 
dékot ki kell cserélni FOR XML NESTED-re. Ezt érzékeli az 
SOL OLEDB provider, kiveszi a FOR XML NESTED-et, és csak 
a SELECT-et küldi el az SOL Servernek. Ezt könnyű ellenőriz- 
ni az SOL Server Profilerrel. A módszer kiválóan alkalmas arra 
is, hogy meglévő tárolt eljárások kimenetét xmlként dolgozzuk 
fel. Ha a lekérdezésünk például a GetOrders nevű tárolt eljá- 
rásban van megírva (FOR XML nélkül), a következő paranccsal 
könnyedén xml kimenetet generáltathatunk az eredeti ered- 


ményhalmazbáól: 
cmd.CommandText - "EXEC GetOrders FOR XML NESTED" ; 


Paraméterezett lekérdések 

A lekérdezések külső paraméterekkel kiegészítése az ADO il- 
letve az OLEDB paraméterkezeléséhez hasonló, nem az 
ADO.NET-éhez (nyilván a már tárgyalt OLEDB háttér miatt). 
Az SOL parancsok szövegében a paraméterek helyére 2-et kell 
írni. Ezt azt jelenti, hogy a paramétereket a pozíciójuk alapján 
érhetjük el, ellentétben az ADO.NET-tel, ahol a tárolt eljárá- 
sokhoz hasonlóan nevet adhatunk nekik. 


Készítsünk most egy olyan weboldalt, ami a megadott dátum- 
határok között kilistázza a megrendeléseket. Ehhez a felra- 


kunk két TextBoxot és egy Submit gombot a webformunkra: 
cform id-"orderlist" method-"post" 
runat-"server"5 
ctable id-"SearchTable" runat-"serer"5 
etr: 
ctdoListázás kezdetec/td: 
ctdscasp:textbox id-"StartDate" 
$ runat-"server"51998-03-01c/asp:textbox:c/td: 
€/tr: 
etr: 
actd:sListázás végec/td: 
atd:casp:textbox id-"EndDate" 
$ runat-"server"51998-03-03c/asp:textboxsc/tds 
c/tr: 
etr: 
ctd colspan-"2"5cinput type-"submit" 
$ value-"Submit" id-"Submitl" 
$ name-"Submitl" runat-"server"5c/td: 
S/Exs 
c/tables 
c/form: 


A gomb megnyomására az alábbi kódrészletet hajtjuk végre: 
DateTime start - DateTime.Parse(StartDate.Text) 
DateTime end - DateTime.Parse(EndDate.Text) ; 
SalXxmlParameter pStart - cmd.CreateParameter ( ) ; 
pStart.Value - start; 

SalXxmlParameter pEnd - cmd.CreateParameter () ; 
pEnd.Value - end; 

SearchTable.Visible - false; //már nem kell 
cmd.XslPath - Server.MapPath("ord.xslt"); 

cmd. ExecuteToStream(Response.OutputStream) ; 


A kapott szövegeket átalakítjuk dátummá, így a hibás formá- 
tum már a lekérdezés végrehajtása előtt kiderül. Persze itt elég 
sokat el lehet szórakozni a formátumokkal (/d. Culturelnfo, 
DateTimesStyles, stb.), illetve a dátum kinyerését érdemes try- 
catch blokkba rakni, és a felhasználók felé megfelelően kom- 
munikálni a probléma okát. 

Ha a dátumhatárok megvannak, SglXmlIParameter objektumo- 
kat hozunk létre az SagIXkXmICommand CreateParameter() hívá- 
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sával. Nyilván a CreateParameter belül rögzíti a ] ] 


létrehozott paraméterek sorrendjét. A tényle- aim 
szájól pb a ar J es v Ta 

ges értékeket a Value jellemzőn keresztül lehet ze 

elérni. Ezek után a végrehajtás teljesen azonos ) 


a korábbi példákéval. A SearchTable.Visible — 
false; sorral tüntetjük el a kimenetből a kere- 
séshez használt táblázatunkat. 


Az SOL parancs eleje azonos az eddigiekkel, a vége így néz ki: 
WHERE OrderDate BETWEEN ? AND ? 
FOR XML AUTO 


A két kérdőjel helyére kerülnek be a paraméterek. 

XML sablonok és XML nézetek végrehajtása során viszont 
használhatjuk az SglXmlParameter objektum Name jellemző- 
jét is, így ott használhatunk megnevezett paramétereket is. 


Például nézzük az alábbi XML sablont (XML template): 
sorderlist xmlns:sagl-"urn:schemas-microsoft- 
com:xml-sagl"2 
csal:header: 
csal:param name-"StartDate"5c/sal:param: 
csal:param name-"EndDate"5c/sagl:param- 
c/sal:header: 
csagl:gueryz 
SELECT [order] .OrderID, 
OrderDate, 
ProductName, 
detail.UnitPrice, 
Ouantity, 
Discount 
FROM 
(Order Details] detail 
INNER JOIN 
Orders [order] 
ON 
detail.OrderID - 
INNER JOIN 
Products product 
ON 
detail.ProductID - product.ProductID 
WHERE 
OrderDate BETWEEN EStartDate AND GEndDate 
FOR XML AUTO 
c€/sal:gueryz 
c/orderlist: 
Ez nem más, mint a korábbi sg] parancs xml fájlba csomagol- 
va (GetOrders.xm]). 


A sablon megadása: 
//A gyökeret a sablon adja. 
//cmd.RootTag - "orderlist"; 


"9L yunss991W4x / 


[order] . orderID 
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cmd.CommandTrype - SaglXmlCommandType.TemplateFile; 
cmd .CommandText - Server.MapPath("GetOrders.xml" ) ; 


A paramétereket most a nevükkel azonosítjuk, és hogy ez 


tényleg így van, a sorrendjüket szándékosan megcseréltem: 
SalxmlParameter pEnd - cmd.CreateParameter ( ) ; 
pEnd.Name - "€gEndDate"; 

pEnd.Value - end; 


SalxmlParameter pStart - cmd.CreateParametetr ( ) ; 
pStart.Name - "EeStartDate"; 
pStart.Value - start; 


folytatjuk... 
Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.NET 





(11: Letölthető példakódok: http://technet.netacademia.net/download/xml 

[2]: SOLXML 3.0 SP1 http://msdn.microsoft.com/downloads/default.aspY?URL—/downioads/ 
sample.asp?url—/msdn-files/027/001/824/msdncompositedoc.xmi 

BI: MSXML 4 : http://msdn.microsoft.com/downloads/default.aspturl—/downloads/ 
sample.asp?url—/msdn-files/027/001/766/msdncompositedoc.xml 

(41: HTTP1.1 RFC2616: http:/fwww.ietf.org/rfc/ríc2616.txt 
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. NET Akadémia 


VIII. 


Többszálú és aszinkron programozás 


A többszálú programozás az egyik legtipikusabb felhasználói módú programozási terület, ahová csak a 
legelszántabb C-4--- programozók merészkedtek el. Windows API használatával időnként tényleg nehéz 
helyzetben találjuk magunkat, de a Common Language Runtime nagyon leegyszerűsíti az életünket, ha 
menedzselt környezetben kell többszálú programokat fejleszteni. 


Sajnos azonban látni fogjuk, hogy a többszálú programozás- 
ban nem a szálak létrehozása, hanem a párhuzamosan futó 
szálak szinkronizációja lesz a kihívás. 

Cikkünkben először áttekintjük a szálkezelés alapjait, megnéz- 
zük a szinkronizációs lehetőségeket, majd a következő részek- 
ben megismerünk egy témába vágó programozási módszert, 
az aszinkron programozást. 





A menedzselt futtatási környezet 

Mielőtt vadul nekilátnánk szálakat létrehozni, nem árt köze- 
lebbről megismerni azt a keretet, amelyben a szálaink futni 
fognak: a CLR-t. 

Alapkérdés: mi az a thread, magyarul szál? A szál a program- 
futtatás alapvető egysége, amelyhez az operációs rendszer 
processzoridőt rendel. Minden szálnak saját belső struktúrái 
vannak, amelyben az operációs rendszer elmenti a szál pilla- 
natnyi állapotát, mielőtt átkapcsolna egy újabb szál végrehaj- 
tására. Mivel a szálak közötti végrehajtás-átkapcsolás tipikusan 
másodpercenként több tízszer, több százszor zajlik le, a kívül- 
álló úgy érzékeli, hogy a szálak párhuzamosan futnak. 


Az Windows32 a szálakat processzek belsejében futtatja. Egy 
processzben akárhány szál futhat, és a szálak közvetlenül 
együtt tudnak működni: közös memóriaterületen dolgoznak a 
processz belsejében. 

Ezzel szemben különböző processzekben dolgozó szálak nem 
tudnak közvetlenül kommunikálni, nem látják egymás memó- 
riaterületeit. Pont ezért létezik a processz fogalma, mely elszi- 
geteltségi egységként funkcionál. 

.NET-ben a Win32-es processzt tovább bontották, és bennük 
akárhány Application Domain létezhet. Az AppDomain tulaj- 
donképpen menedzselt processznek felel meg. A menedzselt 
programok részére éppoly erős elszigeteltséget biztosít, mint a 
Win32 processz, csak sokkal kevesebb plusz memória- és pro- 
cesszorterheléssel. 

Milyen kapcsolat van az AppDomainek és a szálak között? Ál- 
talában egy AppDomainben akárhány szál futhat párhuzamo- 
san, azonban (és ez teljesen eltérő a processzektól) egy 
AppDomainben futó szál könnyedén átléphet egy másik 
AppDomainbe, ott végrehajthat némi kódot, majd visszatérhet 
az induló Domainbe. Ilyen természetesen processzek között 
nem működik. Ez a helyzet akkor áll elő, ha egy AppDomain 
létrehoz egy új AppDomaint, abba betölt egy assemblyt, és a 
betöltött assemblyből létrehozott típusnak meghívja egy metó- 
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dusát. Ekkor a hívás ugyan a Remoting (lásd előző cikkünket) 
felületén keresztül zajlik le, de az új AppDomain kódját akkor 
is a hívó domain szála fogja végrehajtani. 




















Ed Szálak és AppDormainek kapcsolata 


Bár az AppDomainek témája nem tartozik szorosan a cikk fő 
vonulatához, de az érdeklődőknek íme egy AppDomain-létre- 
hozás, assemblybetöltés, típuslétrehozás és -hívás Remotingon 
keresztül. A példakód: 


using System; 
using System.Reflection; 
using System.Threading; 


namespace AppDomainTest ( 

class MainClass ( 
static void Main(string[] args) ( 
Console.WriteLine("Main metódus." ); 
Info.ShowInfo() ; 


AppDomain appDomain; 
appDomain - 
AppDomain.CreateDomain ("Másik AppDomain?" ); 
string assName - 
Assembly .GetExecutingAssembly ( ) .FullName; 
WorkerDomain dom; 
dom - (WorkerDomain) 
4 appDomain.CreatelnstanceAndUnwrap( 
$4 assName, "AppDomainTest.WorkerDomain?" ) ; 
dom. Process () ; 
Console.ReadLine() ; 
8 
, 
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csummaryz 
MarshalByRefObject, 
/// elérhető. 
[7/ c/summaryz 
public class WorkerDomain : MarshalByRefObject ( 
public void Process() ( 
Console.WriteLine("Process metódus."); 
Info.ShowInfo() ; 
b 
J 


így remotingon keresztül 


public class Info ( 
public static void ShowInfo() ( 
Console.WriteLine ( "Appdomain: (0)", 
s AppDomain.CurrentDomain.FriendlyName) ; 
Console.WriteLine("Win32 Thread ID: (0)", 
b AppDomain.GetCurrentThreadId-()); 
cConsole.WriteLine("Menedzselt Thread ID: 
$ — Thread.CurrentThread.GetHashCode()); 
) 
i 
J 
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A kimenet: 





Látható, hogy a hívás során ugyanaz a szál először a kiinduló 
AppDomainben futtatott kódot, majd az újonnan létrehozott 
Domainben (azonos a Thread ID). 


A Thread osztály 

Alapvetően a szál egy operációsrendszer-konstrukció, az hoz- 
za létre, allokál neki processzort és semmisíti meg. Emiatt a 
System.Threading.Thread osztály csak egy burkolótípus a 
Win32-es Thread API köré, nem sok újdonságot ad hozzá. 
Minden egyes CLR-ben létrehozott vagy a CLR-ben futó alkal- 
mazásba kívülről belehívó szál köré kiépül egy Thread objek- 
tumpéldány, amely segítségével egyszerűen kezelhetjük a szá- 
lakat. 


Első lépésként nézzük meg egy új szál létrehozását és elindí- 
tását: 


using System; 
using System.Threading; 


class Tester ( 
ISTAThread] 
static void Main(string[] args) ( 
Console.WriteLine("Fő szál, id-(0)", 
Thread.CurrentThread.GetHashCode ( ) ) ; 
Thread t1 - new Thread( 
new ThreadStart(TiMetodus) ) ; 
t1.Start(); 
) 
static void TlMetodus() ( 
Console.WriteLine("Szál létrejött, id-(0)", 
"Thread.CurrentThread.GetHashCode ( ) ) ; 
1 
B: 


A Thread konstruktor egy ThreadStart delegate példányt vár 
paraméterül, ez lesz az új szál belépési pontja. A konstruktor 
lefutása után a szál még nem fut, Unstarted állapotban van. Az 
elindítást a Start() metódus hívás váltja ki: 
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Egy szál pillanatnyi állapotát lekérdezhetjük a 
ThreadState jellemzőn keresztül: 


Console.WriteLine(t1.ThreadState) ; 


A különböző állapotokat a ThreadState nevű felsorolás típus- 
ban szedték össze. Az Unstarted állapot közvetlenül a létreho- 
zás után jön létre, mígnem meghívjuk a Start() metódust. Ek- 
kor a szál Running állapotba kerül. Ha a szál megállt (például, 
mert véget ért a szál által végrehajtott metódus), akkor a 
Stopped állapotban találhatjuk. Ezen felül további állapotok is 
léteznek, amelyeket hamarosan számbaveszünk. 

A ThreadStartban megadott delegate példányszintű metódus- 
ra is mutathat, ami kitűnő lehetőséget ad indulási paraméterek 
átvitelére, illetve sok munkaszál létrehozására: 


ArrayList threads - new ArrayList(); 
for(int i-0; icl0; irr) ( 
Szalhuzo sz - new Szalhuzo(); 
sz.PeldanyNo —- i; 
Thread t - new Thread( 
new ThreadStart(sz.TMetodus) ) ; 
threads.Add(t) ; 
t.Start(); 
) 


class Szalhuzo ( 
public int PeldanyNo; 
public void TMetodus() ( 
for(int i-0O; ic5; itt) ( 
Console.WriteLine("Szál (0), iteráció: 
PeldanyNo, i); 


(197, 


Thread.Sleep(5) ; 
1. 
J 


A munkametódusba 5 ms késleltetést tettem, így szépen elver- 
senyezgetnek a szálak egymás között: 


-ol2] 
[a] 
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A Sleep statikus metódus a megadott ideig (milliszekundum) 
blokkolja annak a szálnak a futását, amiben meghívják. 
Hosszabb idők esetén kényelmesebb a TimeSpan paraméterű 
metódus használata. 


Thread. Sleep (TimeSpan. FromMinutes (5) ) ; 


Amikor a szál éppen alszik, az —— állapota 
ThreadState. WaitSleepJoin. Ezt persze nem tudjuk megfigyelni 
magából a szálmetódusából, mivel ha alszik, nem tud végrehajta- 
ni még egy Console.WriteLine-t sem. A megfigyelést nyilván egy 
másik szálból kell megtennünk, például a kiinduló főszálunkból: 


while(true) ( 
for(int i-O; iciO; itr) ( 
Thread t - (Thread) threads[i]; 
if (t.ThreadState — 
b ThreadState.WaitSleepJoin) ( 
Console.WriteLine("Alszok: (0), 
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állapot: 


10. 
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] s (135, i, t.ThreadState) ; 
ezi ) 


A kimenetben szépen látszik, hogy időn- 
ként elkapjuk, amint valamelyik szál alszik: 





EEHEZESZT PI 4 
A példánkban elég bután egy végtelen ciklusban figyeltük a 
szálak működését. Valamilyen módon azért jó lenne kijönni a 
külső while ciklusból akkor, amikor minden szál befejezte a 
működését. Ennek egyik módja lenne, hogy figyeljük, vala- 
mennyi szál Stopped állapotba került-e? 


int stoppedNum - 0; 
while(stoppedNum c 9) ( 
stoppedNum - 0; 
for(int i-O; iciO; i-t-4) ( 
Thread t - (Thread) threads[i]; 
V/özsis 
if (t.ThreadState -- ThreadState.Stopped) 
stoppedNumt--t ; 


A módszer hátránya, hogy a várakozó ciklusunk feleslegesen 
emészti a processzoridőt, hisz végül is pollozzuk mikor van ké- 
szen minden szál. A Task Manager gyönyörű zöld oszloppal 
díjazza kontárságunkat: 


CPU Usage —— CEL NEOt ELÉGÉ Ot teezzzzeze————— zt ...—l 














Id A buta pollozás hatása 


Némi javulást jelent, ha minden vizsgálat után várunk egy 
csöppet (a while ciklusban): 


Thread.Sleep(1) ; 


Ez már processzorbarátabb megoldás: 


CPU Usage — 


CPU Usage History ——— — 





I Barátságban a processzorral 


Ha tényleg nagyon rövid időt akarunk csak várni, nehogy egy 
milliszekundummal később lépjünk ki, mint ahogy a szálak vé- 
get érnek, akkor a Sleep() metódust 0 értékkel kell felparamé- 
terezni. Ezt azt jelenti az OS ütemezőjének, hogy a szálunk 
(amiben kiadtuk a Sleep -et) elvégezte a feladatát, az üteme- 
ző mehet tovább a következő szál futtatására. Ha bármilyen 


eseményt pollozással kell figyelnünk, feltétlenül emlékezzünk 
erre! A Task Manager szeme most is kiugrik száz százalékra, 
de amint bármely más szál kér processzoridőt azonnal meg- 
kapja, nem veszünk el senkitől időt. 

Talán egyesek emlékeznek a különböző elosztott, internetes 
RSA kódtörő és egyéb programokra. Azok megpróbálták a lé- 
tező összes szabad processzoridőt anélkül felhasználni, hogy 
más folyamatokat lelassítanának. Nos, azok pont ezt a mód- 
szert használták. 

Ha tényleg nem akarunk tolakodóak lenni, a szálak prioritását 
is alacsonyabbra vehetjük. Erre a szál Priority jellemzője való: 


Thread.CurrentThread.Priority - ThreadPriority.Lowest; 


Ebben a példában még a várakozó ciklusunk előtt kiadjuk a 
fenti sort, így a Maint elindító szálunk Idle prioritással fog fut- 
ni. A Thread statikus CurrentThread jellemzője kényelmes 
hozzáférési lehetőséget biztosít a kódot futtató szálhoz. 

Ha az általunk indított szálak prioritását akarjuk módosítani, 
akkor a szálreferencia ismeretében közvetlenül megtehetjük: 


Thread t - new Thread(...); 
t.Priority - ThreadPriority.Lowest; 


A szálak jellemzői közül lássunk még néhány fontosat. 

Egy szál lehet foreground vagy backgound jellemzőjű. A fore- 
ground szálak életben tartják az elindított programot, azaz 
amíg az összes foreground szál el nem éri a Stopped állapotot, 
a processz futni fog. Természetesen a Main()-t elindító szál 
foreground állapotú, azaz normál esetben a Main() lefutása 
után a programfutás megszakad. 

A háttérben folyamatosan sürgölődő szálak esetén célszerűbb 
a background beállítás, így az általában egyetlen foreground 
szál, a Main() szálának lefutása után a CLR automatikusan le- 
állítja a még futó backgound szálakat, majd terminálja az al- 
kalmazást. Gondoljunk például a Word laptördelőjére vagy 
helyesírás-ellenőrzőjére. Ezek suttyomban futnak a háttérben, 
és ha backgound szálként futnának (az Office még nem me- 
nedzselt alkalmazás), nem kellene velük törődni a program ki- 
lépésekor. 

A jellemző állítása rendkívül egyszerű, például háttérszálakhoz: 


t.IsBackground - true; 


A szálaknak nevet is adhatunk a Name jellemzőn keresztül, di- 
agnosztikai célokból jól jöhet, különösen, hogy a Visual 
Studio.NET Threads ablaka kiírja a szálak nevét is, így debug- 
goláskor nagy segítség lehet az eligazodásban: 













] Name 
-2No Namez 
Szálacskaz 


! Location 
Tester.Main 













Szálacskas — Szalhuzo.TMetodus 
Szálacska6 — Szalhuzo.TMetodus 
Szálacskaz — Szalhuzo.TMetodus 


esz sszszzazll 
EJ Szálak a VS.NET Threads ablakában 


Különösen nekünk magyaroknak (a nem angol anyanyelvűsé- 
günkre, és nem a Szíriuszi származásunkra gondolok) fontos a 
CurrentCulture jellemző. A CurrentCulture egy a szálhoz tar- 
tozó System.Globalization.Culturelnfo osztálypéldányt tárol. 
Ez meghatározza, hogy a ,kulturált", azaz a szál 
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CurrentCulture beállítására érzékeny típusok hogyan alakítják 
át magukat szöveggé, illetve hogyan tudnak szövegeket alapti- 
pusokká átalakítani. 

Például egy szám pénzként történő kiírásakor (,, C" formátum- 
sztring) a kiírás a megfelelő kultúrához tartozó pénznemben 
fog megjelenni: 


INET 2 


Alapértelmezett: $12.40 
Magyar: 12,40 Ft 
Német: 12,40€ 





d A Thread CurrentCulture jellemző hatása az alaptípusok 
kiíratására 


A fenti ablakot megjelenítő kód: 


Thread mThread - Thread.CurrentThread; 
Culturelnfo magyar - new Culturelnfo("HU-hu" ) ; 
cultureIlnfo nemet - new Culturelnfo("DE-de" ) ; 
double d - 12.4; string s; 

s - string.Format("Alap: (O:C)Mn", d); 
mThread.CurrentCulture - magyar; 

s 4- string.Format("Magyar: (0:CjYin", d); 
mThread.CurrentCulture - nemet; 

S 47 string.Format("Német: (0:C)", d); 
MessageBox . Show(s) ; 


Egy másik jellemző, a CurrentUlCulture hasonló célokra felépített 
jellemző, csak ez a ResourceManager osztályon keresztül felolva- 
sott assembly erőforrások nyelvére van befolyással. Erről bőveb- 
ben majd egy későbbi Windows Forms cikkben fogok értekezni. 


Thread metódusok 

Korábbi példánkban a szálak állapotát vizsgálva vártuk meg, 
hogy minden háttérszál végezzen a munkájával. Mivel a más 
szálakra várakozás nagyon gyakori feladat, erre a célra egy kü- 
lön metódust, a Join()-t találtak ki. A Join0)-t az a szál hívja 
meg, amelyik be akarja várni egy másik befejezését: 


Thread th - new Thread( 
new ThreadStart(T2Metodus) ) ; 
th.Start(); 
th.Join(); 
Console.WriteLine("Thread T2 végetért"); 


static void T2Metodus() ( 
Console.WriteLine("T2 szál létrejött."); 
Console.WriteLine("T2 elalszik."); 
Thread.Sleep(1000) ; 
Console.WriteLine("T2 szál felébredt."); 


Azaz esetünkben a főszálunk bevárja az újonnan létrehozott 
szál befejeződését: 





Amikor egy szál a Sleep() meghívásától alszik, az állapota 
WaitSleepJoin. Ha a Join() hatására blokkolódik, szintén ebbe 
az állapotba kerül, innen az állapot neve. A harmadik tagról, a 
Waitről hamarosan szó lesz. 

Hogyan írhatjuk át a korábbi példánkat, hogy mind a tíz se- 
gédszál futását bevárjuk? Első körben hajlamosak lennénk a 


szálak elindítása után azonnal Join()-olni az új szálhoz, ám ez- 
zel a következő szál csak az előző vége után indulna el: 


for(int i-O; ici0O; irt) ( 
Szalhuzo sz - new Szalhuzo(); 
sz.PeldanyNo -— i; 
Thread t - new Thread( 
new ThreadStart(sz.TMetodus) ) ; 
threads.Add(t) ; 
t.Start(); 


t.Join(); //ajaj, nem lesz ez így jó! 


A kimenetből látható, hogy a szálak csak egymás után tudnak 
lefutni. Ezért külön kell választanunk a létrehozás-indítás és a 
bevárás fázisokat: 


threads.Clear() ; 
for(int i-0O; ici0; itt) ( 
Szalhuzo sz - new Szalhuzo(); 
sz.PeldanyNo - i; 
Thread t - new Thread( 
new ThreadStart(sz.TMetodus) ) ; 
threads.Addí(t) ; 
t.Start(); 


) 
for(int i-0; icli0; it4) ( 

Thread t - (Thread) threads[i]; 
//ez már igen 


t.Join(); 
) 





EI A rosszul irányzott Join0 sorbaállította a szálakat 


Itt nem baj, ha felakad a várakozó ciklus valamelyik Join0-on, 
hisz már minden szál dolgozik, az első részben már elindítottuk. 
A Join0-nak több előnye van a korábbi pollozással szemben. 
Mivel a szálak állapotát alapvetően az operációs rendszer isme- 
ri legközelebbről, ha a szálak várakoznak egymásra, az operáci- 
ós rendszer ütemezője tudja, hogy mikor lehet elindítani a vá- 
rakozó szálat, hisz tudja, mikor ért véget a blokkoló szál. Emiatt 
a várakozás nem visz el szinte semmilyen plusz processzoridőt, 
ellentétben a ciklusos pollozással. A Join() mögött valójában a 
WaitForSingleObject Win32 API függvény hívása zajlik le. 

A Join() másik előnye, hogy lehetséges korlátozott ideig is vár- 
ni. Vagy véget ér a blokkoló szál futása, vagy letelik a megadott 
időintervallum: 


th - new Thread(new ThreadStart(T3Metodus) ) ; 
th.Start(); 
Console.WriteLine("Várunk 500 ms-ig"); 
bool b - th.Join(500); 
if (b) 
Console.WriteLine("Thread T3 véget ért"); 
else 
Console.WriteLine("Thread T3 még fut, 
B de nem várunk tovább"); 
th - new Thread(new ThreadStart(T3Metodus) ) ; 
th.Start(); 
Console.WriteLine("Várunk 1200 ms-ig"); 
b - th.Join(1200); 
if (b) 
Console.WriteLine("Thread T3 végetért") ; 
else 
Console.WriteLine("Thread T3 mégfut, 
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b de nem várunk tovább"); 


static void T3Metodus() ( 
Console.WriteLine("T3 szál létrejött."); 
Thread.Sleep(1000) ; 

, 


—] 


Az első esetben még nem ér véget a létreho- 
zott szál futása, de a Join() visszatér, mert letelt a megadott fél 
másodperc. A második esetben türelmesebbre vettük a Join()- 
t, akkor már.kap elég időt a háttérszál: 


2 nem várunk t 








WaitHandle 

Több szál munkáját bevárni mindenképpen ciklusszervezést 
igényelt, habár a Join()-os megoldás jelentősen egyszerűbb 
lett. 

Több folyamat közötti szinkronizációra sokkal kényelmesebb 
lehetőséget biztosítanak a WaitHandle osztály és leszármazot- 
tai. A Join() alapvető hiányossága, hogy csak a szálak vége ese- 
tén jelez. Pedig sokszor cél, hogy egyes szálak a munkájuk bi- 
zonyos szintjén bevárják a többieket, majd folytassák munká- 
jukat. Ekkor vethetjük be a WaitHandle családot. 

A WaitHandle osztálynak három leszármazottja van: az 
AutoResetEvent, a ManualResetEvent és a Mutex. A család 
tagjai mögött Win32 OS handle-ök állnak, így programunk 
más rendszerre portoláskor lehet, hogy gondban leszünk. Ha 
kifejezetten fontos a többplatformos futtathatóság, használjuk 
a később tárgyalandó Monitor osztályt. 

Az AutoResetEvent és a ManualResetEvent lehet Signaled és 
Nonsignaled állapotban. Az egyszerűség kedvéért nevezzük 
bekapcsolt és kikapcsolt állapotnak. 

A bekapcsolás a Set() metódus hívásával, a kikapcsolás a Re- 
set() hívásával érhető el. A WaitHandle osztály WaitAll() metó- 
dusa WaitHandle objektumok tömbjét vár paraméterül, és ad- 
dig blokkolja az aktuális szál futását, míg a paraméterként 
megadott WaitHandle objektumok bekapcsolt (Signaled) álla- 
potba nem kerülnek. 

Nézzük meg ezt egy példán keresztül. Létrehozunk 10 szálat, 
amelyek végrehajtásuk egy bizonyos pontján visszajeleznek a 
főszálnak, hogy eddig készen vannak. A szálat futtató metó- 
dust tartalmazó osztály definíciója: 


class Szalhuzo ( 
public int PeldanyNo; 
public ManualResetEvent eddigoOk; 
public ManualResetEvent vege; 


public void T4Metodus() ( 

Console.WriteLine("T4((0)) szál létrejött.", 
PeldanyNo) ; 

Thread.Sleep(200) ; 
//Visszajelzünk, eddig kész vagyunk. 
eddigok.Set () ; 
Thread.Sleep(2000); //Dolgozunk tovább... 
vege.Set(); 

) 

) 


Minden egyes szál mögött ebből az osztályból áll egy-egy pél- 
dány, így mindegyik tartalmaz két ManualResetEvent referen- 
ciát (eddigOk és vege), melyet majd a szálakat létrehozó kód 
hoz létre: 
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// ManualResetEvent használata 
ManualResetEvent [] eddigoOk - new ManualResetEvent [10]; 
ManualResetEvent [] vege - new ManualResetEvent [10]; 
for(int i-0O; ici0O; ir4) ( 

Szalhuzo sz - new Szalhuzo(); 

sz.PeldanyNo - i; 

Thread t - new Thread(new 

ThreadStart (sz. T4Metodus) ) ; 
threads.Add(t); 


//Induláskor kikapcsolt 
eddigok[i] - new ManualResetEvent (false); 
sz.eddigOk - eddigok[i]; 
vegeli] - new ManualResetEvent (false); 
sz.vege - vege[i)]; 
t.Start(); 
) s 
//Várunk... 
WaitHandle.WaitAll (eddigok) ; 
Console.WriteLine("Mindenki végzett a részfeladatával."); 
//Várunk tovább... 
WaitHandle.WaitAll(vege) ; 
Console.WriteLine("Minden szál terminált."); 


Minden szálhoz létrehozunk két ManualResetEvent példányt. 
Mindkettő kikapcsolt (Nonsignaled) állapotban lesz, ezért a 
false a konstruktorban. A példányokat átadjuk a szálak osztá- 
lyainak az eddigOk és vege mezőkön keresztül. 

A szálak elindulnak, dolgoznak egy darabig, majd visszaje- 
leznek, hogy az adott szintig készen vannak a feladatukkal. 
Ezt egyszerűen az eddigOk.Set() hívásával teszik meg. Ettől a 
példányhoz tartozó ManualResetEvent bekapcsolt állapotba 
kerül. 

A főszál (karmester) a WaitHandle. WaitAllreddigOk) segítsé- 
gével bevárja, míg az összes szál végez a feladatával. A 
WaitAll addig vár, míg az összes WaitHandle leszármazott 
(ManualResetEvent) példány a megadott tömbben Signaled 
(bekapcsolt) állapotba nem kerül. Hasonlóan várunk arra az 
eseményre is, amikor minden szál kilép. 

A várakozás ismét operációs rendszer szinten van megvalósít- 
va, azért nem igényel jelentős erőforrásokat. 

Abban az esetben, ha már a leggyorsabban visszajelző szál 
után tovább akarunk lépni, használjuk a  Wait- 
Handle.WaitAny() metódust. Például több szálon kiküldünk 
kéréseket valamilyen tükrözött (mirrored) internetes erőforrás 
elérésére, majd a leggyorsabban válaszolót futni hagyjuk, a 
többi szálat pedig megállítjuk. Erre a célra kiválóan használ- 
ható a WaitAny() metódus. 

Ha egyetlen szál bizonyos pontjáig kell csak várnunk, hasz- 
nálhatjuk a példányszintű WaitOne() metódust. Ugye emlék- 
szünk, ennek előnye a Thread.Join()-nal szemben, hogy a se- 
gédszál végrehajtásának bármely pontján visszajelezhetünk, 
míg a Join() csak a szál terminálásakor jelez vissza. 

A Wait() metódusok is képesek az időtúllépésre figyelni, így 
biztosak lehetünk abban, hogy a várakozó szál nem blokko- 
lódik meghatározatlan ideig. 

Mi a különbség a ManualResetEvent és az AutoResetEvent 
között? A bekapcsolt  (Signaled) állapotban lévő 
AutoResetEvent automatikusan Nonsignaled (kikapcsolt) álla- 
potba kerül, ha az őrá várakozó szál várakozása véget ért. Az- 
az, ha a főszál várakozik egy háttérszálra, ami bekapcsol egy 
AutoResetEventöt, a várakozás után az AutoResetEvent auto- 
matikusan Resetelődik, azaz Nonsignaled állapotba kerül. Az 
alábbi példa szemlélteti a két WaitHandle közötti különbsé- 
get. Némi trükközésre azért van szükség, mert közvetlenül 
nem lehet lekérni a belső kikapcsot/bekapcsolt állapotot, így 
csak ismételt - időtúllépéssel megvalósított - várakozással tud- 
juk kitalálni melyik milyen állapotban van a várakozás után. 
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bool bAuto - test.Auto.WaitOne (1000, false); 
string state - bAuto ? "Signaled": "Nonsignaled"; 
cConsole.WriteLine("AutoResetEvent várakozás 

HW előtt: (0)", state); A 

baAuto - test.Auto.WaitOne(1000, false); 

state - bAuto ? "Signaled" : "Nonsignaled"; 
Console.WriteLine("AutoResetEvent várakozás 

b után: (0)", state); 


bool bMan - test.Man.WaitOne(1000, false); 
state - bMan ? "Signaled" : "Nonsignaled"; 
Console.WriteLine ( "ManualResetEvent várakozás 
$ előtt: (07, state); 

bMan - test.Man.WaitOne(1000, false); 

state - bMan ? "Signaled" : "Nonsignaled"; 
Console.WriteLine (( "ManualResetEvent: várakozás 
$ után (0)", state); 


Látható, hogy az AutoResetEvent méltó a nevére, és automa- 
tikusan kikapcsolja magát, ha beteljesítette feladatát: 


ignaled 
TELEL NEE NE ÉT! 





elott: Signaled 
után Signaled 





Mutex 

A Mutex is WaitHandie utód, ám különlegessége, hogy 
processzeken átívelő szinkronizációra is alkalmas. Ehhez a 
Mutex példányunkat névvel kell ellátni, amely névnek a szá- 
míitógépen egyedinek kell lenni. 

Egy mutexobjektumot egyszerre mindig csak egy szál birtokol- 
hat. Amíg a szálnál a Mutex, a többi szál kénytelen rá várakoz- 
ni. Amikor a szál végzett a munkájával, meghívja a Mutex 
ReleaseMutex metódusát, így a következő várakozó szál kap- 
ja meg a vezérlést. 

Az alábbi példa egy olyan WinForms program Main() metódu- 
sát mutatja, amelyből csak egy példány futhat: 


ADAVURÁA [RT 





static void Main() ( 
bool first; 
Mutex m - new Mutex(true, "OnlyOne", out first); 
E SATAGJET 
try ( 
Application.Run(new Formil.()); 
ij) 
finally ( 
m.ReleaseMutex ( ) ; 
) 
) 
else ( 
MessageBox.Show("Már fut egy példány", 
"Mutex", MessageBoxButtons.OK) ; 
1 
) 


Folytatjuk... 


Soczó Zsolt MCSE, MCSD, MCAD, MCDBA 
Zsolt.Soczo(Oonetacademia.NET 





http://vilagokorseg.hu 





KÖSZÖNJÜK, HOGY FELINSTAL- 
LÁLTAD EZT A SZINES LÉZER- 
NYOMTATÓT. TUDOD, MILYEN 
DRÁGA VOLT? ÉS MILYEN 
DRÁGA VELE EGY OLDAL? 


EZÉRT HA KÉRHETNÉLEK, NE 
MONDD EL SENKINEK, HOGY 
NEKÜNK ILYENÜNK VAN. 
MÉG AZ INFORMATIKÁN SEM. 
MÉG A BARÁTAIDNAK SEM, 


OKÉ, OKÉ! 
A TESZT- 
OLDALT 
MEGEHETEM? 
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Az UML 


1. rész 


A modellezés témát folytatva, pontosabban részletezve UML sorozatom első részében a módszer kiala- 


kulásának körülményeit szeretném bemutatni, illetve néhány olyan alapfogalmat, amelyek megértése el- 


engedhetetlen a későbbiek megértéséhez. 


Az igények 

Az előző számban már írtam arról, hogy csekélyértelmű med- 
vebocs korom óta mennyit fejlődtem, legalábbis a programo- 
zási szokások terén. Eleinte minden előzetes tervezés nélkül 
vágtam bele a dolgokba, majd az első hibák, memória-túl- 
csordulások és reménytelennek tűnő debuggolások után gon- 
dolkodni is elkezdtem (mekkora előrelépés volt ez!). Egy idő 
után megtanultam, hogy ha előre gondolkodom, sokkal 
messzebb jutok. 


Valahogy így történt ez a szoftverfejlesztéssel, mint globális 
fogalommal is. A megvalósítható dolgokkal együtt az igé- 
nyek is egyre nőttek, nőnek ma is, a növekvő igényeknek 
meg kell felelni, egyre több, addig kivitelezhetetlennek tűnő 
dolgot meg kell valósítani, és így tovább. Úgy tűnik, ebből 
az ördögi körből nincs kiszállás. A folyamatosan növekvő 
igények kielégítéséhez pedig hatékony technikák és mód- 
szerek szükségesek. 


Ezeket a mindig újabb és újabb és újabb fogásokat persze fo- 
lyamatosan tanulni kell, ha lépést akarunk tartani rohanó vilá- 
gunk kihívásaival. Sok informatikus szakember azonban még 
mindig a több évtizedes, ,jól bevált" módszereket használja, 
az idő múlásával pedig egyre nehezebben és nehézkesebben 
változtatja meg ezeket a szokásokat, beidegződéseket. 

Sajnos ezen egyik pillanatról a másikra nem tudunk változtat- 
ni. Nem is létezik módszer, amellyel mindenki meggyőzhető 
lenne, talán nem is cél ez. Én egyetlen dolgot szeretnék most 
megpróbálni: bemutatni az UML-t, mint módszertant, és érve- 
ket felsorakoztatni mellette. 

Először is gondoljuk végig, hogy egy átlagos, hétköznapi fej- 
lesztőnek (persze ha létezik ilyen...) milyen igényei lehetnek 
egy tervezési metodikával kapcsolatban: 


. jól elkülöníthető, személyekre és csoportokra egyértelműen 
felbontható, pontosan definiált feladatokat határozzon 
meg, elősegítve a hatékony csapatmunkát; 

" pontosan definiálja a fejlesztendő terméket; 

. a termék minőségének méréséhez (és eléréséhez) egyértel- 
mű mérési szempontokat állapítson meg; 

" a felhasználói igényeket teljes mértékben vegye figyelembe, 
a fejlesztők és a megrendelők között magasfokú együttmű- 
ködést tegyen lehetővé; 

. az egyéni és csoportos feladatok egységes kezelését is tegye 
lehetővé, ugyanakkor ne jelentsen túl szigorú megkötése- 
ket sem, ezáltal biztosítson teret az egyéni fejlesztői kreati- 
vitásnak. 


Természetes igény, hogy mindezen követelményeknek egy 
szemléletes, sokatmondó ábrázolásmódot feleltessünk meg, 
amely érthető mindenki számára. Ezáltal a fejlesztők közötti 


working with windows 


belső, és a kereskedők, megrendelők, felhasználók felé irá- 
nyuló külső kommunikáció is egyszerűbbé, egyértelműbbé 
válhat. 


A ,sikersztori" 

Az egységesítés első gondolata a "70-es évek közepén me- 
rült fel, és persze eleinte korántsem egységes javaslatok 
születtek. (Sajnos sok helyen ma is jellemző, hogy egy fej- 
lesztőnek annyi jelölésmódot, ábrázolási technikát kell is- 
mernie, ahány különböző projektben dolgozik.) 

A szoftverek komplexitásának növekedésével és az objek- 
tumorientált nyelvek megjelenésével, terjedésével egyre 
sürgetőbb lett új, mindenki által használható tervezési, 
elemzési módszerek és egységes nyelvek, jelölésrendsze- 
rek kidolgozása. A "90-es évek elejéig több javaslat is szü- 
letett, ezek többsége azonban nem felelt meg az előbb fel- 
sorolt igényeknek (legalábbis nem mindegyiknek), illetve a 
fejlesztendő rendszer bonyolultságának, az egyre növekvő 
problématér nagyságának kezelése is kívánalmakat ha- 
gyott maga után. 

Ekkor azonban jött a Nagy Áttörés: olyan új módszertanok 
jelentek meg, amelyek sikeresen megfeleltek a kihívásnak, 
és kiállták a fejlesztők próbáját. Ilyen eszközök voltak pél- 
dául: Coad-Yourdon, Fusion, Martin-Odell, OMT, OOSE, 
Shlaer-Mellor, stb. [1] 


Az egységesítés 

Három élvonalbeli fejlesztő (Grady Booch, Ivar Jacobson 
és James Rumabugh) felismerte az igényt egy egységes 
módszertan kidolgozására, így összefogtak, hogy az addig 
megszületett metodikák előnyös tulajdonságait kiemeljék, 
és azok alapján egy közös koncepciót dolgozzanak ki. Az 
ő munkásságuknak köszönhetően, több más szerző mód- 
szertanának és tapasztalatainak felhasználásával született 
meg 1997-ben az UML (Unified Modeling Language) mo- 
dellezőnyelv, illetve 1998-ban a RUP (Rational Unified 
Process) módszertan (később több, UML-re építő mód- 
szertant is kidolgoztak a szoftvercégek). 


Mindeközben alakult ki az a fejlesztési metodika is, ame- 
lyet inkrementális fejlesztésnek nevezünk. Ezt az a felis- 
merés hívta életre, hogy a gyakorlatban a legtöbb szoftver 
életének nagyobbik részét teszi ki (és a költségek nagyobb 
részét is igényli) az újabb és újabb verziók előállítása, a 
különböző módosítások végrehajtása, korábbi hibák kija- 
vítása, hiányosságok pótlása. Ebben a folyamatban az új 
szoftver mindössze az első változat előállítását képviseli. A 
,semmiből" létrehozott verzió után az újabbakat mindig a 
meglévő változatok módosításával, kiegészítésével hozzuk 
létre. 
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Egy-egy verzió megvalósítása azonban hosszú ideig (akár 
évekig is) elhúzódhat, közben a fejlesztők egyre több dol- 
gok megtanulnak, tapasztalnak, így az új ismeretek fényé- 
ben szükség lehet a követelmények módosítására (ugye is- 
merős a helyzet?). Ezért célszerű lehet egy verzió készíté- 
sét több kisebb lépésben, alváltozatok egymásutánjaként 
előállítani. Ezt a folyamatot nevezzük a fejlesztés inkre- 
mentális modelljének. Ennek során lehetőség van arra, 
hogy a rendszer problematikus részeit fejlesszük ki elő- 
ször, majd ehhez hozzáfejlesztjük az újabb és újabb rész- 
leteket. (Először többnyire a rendszer viselkedését és ke- 
zelési stílusát érzékeltetjük, vagyis a felhasználói felülete- 
ket készítjük el.) 


A rendszer tehát nem egyenletesen fejlődik, hanem bizo- 
nyos részeivel egészen a megvalósításig előreszaladunk, 
tapasztalatokat gyűjtünk, és az elkészült részekhez rakjuk 
hozzá a még hiányzókat. 


A másik, meghatározó paradigma az architektúraszemléle- 
tű fejlesztés. Ez azt jelenti, hogy a rendszer architektúráját 
különböző nézetekben képzeljük el, így a modellt sokkal 
jobban le lehet írni, mintha egyetlen diagramba szeret- 
nénk mindent besűríteni. 

Ezzel el is érkeztünk jelen cikksorozatom témájához, az 
UML-hez. 


Az UML 

Az UML egy szabványos, egységesített modellezőnyelv, 
amelynek segítségével a fenti leírások, fejlesztési modellek 
rendkívül jól szemléltethetőek; a tervezés, a specifikáció, 
a dokumentálás mind grafikus formában, beszédes ábrák, 
diagramok, táblázatok segítségével végezhető. A legtöbb 
vezető szoftvervállalat felismerte már az UML-ben rejtőző 
lehetőségeket, foglalkozik a szabvány továbbfejlesztésé- 
vel, így ma már az UML-eszközök kínálata szerfelett szé- 
les, mindenki megtalálhatja a számára legmegfelelőbbet. 
A szoftverfejlesztők egymás közötti, és a felhasználók felé 
irányuló kommunikációt csak egy közösen elfogadott, 
mindenki által ismert modellezőnyelv teszi lehetővé. A 
legtöbb fejlesztési módszertan ajánl valamiféle jelölés- 
rendszert, viszont a nyelv és a tervezési módszer élesen el- 
különíthető (ha kész a terv, és azt valamilyen módon is- 
mertetni tudjuk a többiekkel, akkor már mindegy, hogy 
hogyan, milyen módon jutottunk el a kész tervig). Ezt is- 
merték fel az UML készítői, és fejlesztették ki a jelölés- 
rendszert. 


A grafikus szemléltetés rendkívül hatékony módszer, 
azonban szem előtt kell tartanunk, hogy a fejlesztésben 
részt vevő különböző szakemberek mind különböző 
szemszögből szemlélik a rendszert, illetve ugyanaz a szak- 
ember is láthatja másképp ugyanazt a rendszert a fejlesz- 
tés más és más szakaszaiban. Ezért olyan módszert kell al- 
kalmazni, amely képes kezelni ezt a sokrétűséget, viszont 
kellően egyszerű ahhoz, hogy széles körben elterjedjen. 


Az UML nézetei 

Az UML-ben mindez úgy valósul meg, hogy egy rendszer- 
hez több különböző nézetet rendelünk, melyek kiegészí- 
tik, és bizonyos értelemben át is fedik egymást (lásd az áb- 
rát). A rendszerről oly módon kapunk teljes képet, ha 
ezekre a nézetekre együtt, egy egészként tekintünk. 
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Id Az UML nézetei 


1. A használati eset nézet (use case view) 

A rendszer viselkedését, funkcionalitását írja le a szerep- 
lők és a feladatok megjelölésével, a felhasználó szemszö- 
géből nézve. (A szereplő (actor) olyan személy vagy 
elem, amely kapcsolatban áll a rendszerrel, és aktívan 
kommunikál azzal, funkciókat indít el, vagy hajt végre.) 
A használati esetek jól meghatározott funkciók, amelyek 
végrehajtása üzenetváltást kíván. Meghatározó szerepet 
játszanak a fejlesztési folyamatban, hiszen a működés le- 
írása a többi nézetet is jelentősen befolyásolja. 


2. A komponens/implementációs nézet (component view) 
A rendszer struktúráját, a progyramkomponensek, állo- 
mányok kapcsolatát írja le. Elsősorban a programfej- 
lesztők használják, hiszen az elemek, kódkomponensek 
egyetlen működőképes rendszerré integrálását valósítja 
meg. 


3. A folyamatnézet (process view) 
A rendszert folyamataira, végrehajtható egységeire 
bontva ábrázolja. Célja a párhuzamosítható műveletek 
felismerése, az aszinkron események megfelelő kezelé- 
se, ezáltal hatékony erőforrás-gazdálkodás elérése. 


4. A telepítési működési nézet (deployment view) 
A rendszer fizikai felépítését rögzíti, a hardvertopológi- 
át, az adott szoítverkomponensek által igényelt erőfor- 
rásokat írja le. 


5. A logikai/tervezési nézet (design view) 
Azokat az elemeket, feltételeket határozza meg, ame- 
lyek a megfelelő működéshez kellenek. Elsősorban a 
tervezők és fejlesztők számára fontos, hiszen a rendszer 
statikus struktúráját, az együttműködést, az objektumok 
közötti kommunikációt írja le. Itt kell pontosan megha- 
tározni a belső struktúrát és interfészeket is. 


Elemek és relációk 


A rendszer egyes nézeteinek statikus és dinamikus sajátos- 
ságait különböző diagramokkal fejezhetjük ki, amelyek a 
rendszer elemei közötti relációkat írják le, több különbö- 
ző szemszögből nézve. 

Az UML négy relációtípust különböztet meg: 


1. függőség (dependency) 
Két elem között akkor áll fenn, ha az egyik (a független) 
elem változása hatással van a másik (a függő) elemre. 
Kölcsönös a függőség akkor, ha mindegyik elem hatás- 
sal van a másikra. 
Grafikus ábrázolásában a szaggatott nyíl a független 
elem felé mutat. 
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] 2. asszociáció (association) 
ete 


s Tem Az objektumok kapcsolatát, ezek struk- 
ee túráját határozza meg. Speciális esete a -egyenlők: bool - 
em rész-egész viszony, amely kétféle lehet: 
aggregáció vagy kompozíció. Aggregáció 

esetén a rész az egészhez tartozik, de 

önmagában is létező entitás, míg kompozíció esetén a 

rész önmagában nem létezhet, csak az egész eleme- 
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ként. 
A szemléltető nyílon jelöljük az asszociáció irányát, 
multiplicitását. Rész-egész viszony esetén az egésznél 


lévő vonalvég egy csúcsára állított, aggregációnál ,lyu- 


kas", kompozíciónál tömött rombusz. 


3. általánosítás és specializáció (generalization/ specifica 
tion) 


Az objektumok speciális viszonya, gyermek-szülő kap- 
csolat, amelyben a fölérendelt elem az általános, az 


alárendelt a specializált. 
Ábrázolása egy , lyukas" nyíl, amely a szülő felé mutat. 


4. megvalósítás (realization) 


Annak kifejezése, hogy egy osztály biztosít egy másikat 


arról, hogy elvégez számára egy bizonyos feladatot. 
Grafikus szimbóluma egy szaggatott, , lyukas" fejű nyíl. 
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Diagramok 

A diagramok olyan gráfok, amelyek csomópontjai eleme- 
ket, élei az elemek közötti kapcsolatokat képviselik. A kü- 
lönböző diagramok közös elemeket is tartalmazhatnak, hi- 
szen ugyanazt a rendszert ábrázoljuk többféle megközelí- 
tésben. Az UML-ben két nagy csoportról, statikus és dina- 
mikus diagramokról beszélünk. 

A statikus diagramoknak öt fajtáját különböztetjük meg: 


1. Osztály-diagram (class diagram) 
Az osztályok, interfészek, ezek együttműködésének és 
kapcsolataiknak ábrázolására szolgál. 
Egy tipikus osztálydiagramot mutat a következő ábra, 
melyet Orwell: Állatfarmja alapján rajzolhatunk fel. (Bi- 
zonyára mindenki ismeri a nagysikerű regényt.) 
Az alábbi ábráról jól látható, hogy az osztályokat olyan 
téglalapokkal jelöljük, amelyek három részből állnak: 
felső harmadában az osztály neve, középen az osztály 
attribútumai, alul pedig az osztályhoz tartozó metódu- 
sok szerepelnek. 


Disznók 


-egyenlőbbek: bool 








Dolgozik) 














Id Osztálydiagram (, Minden állat egyenlő, de egyes ál- 
latok egyenlőbbek a többinél") 


A nyilak mentén érvényesek az öröklési szabályok, azaz 
minden gyermek-osztály rendelkezik egy bool típusú 
egyenlők attribútummal, míg a Disznók osztálynak még 
egy egyenlőbbek nevű attribútuma is van. A Lovak dol- 
goznak, a Tyúkok kapirgálnak és bizonyos számú tojást 
tojnak (például éves szinten). 

Az attribútumok előtt szereplő apró jelek a következő- 
ket jelenthetik: 

4 : public 

- : private 

A : protected 

attribútumról van szó. 


2. Objektum-diagram (object diagram) 


Az osztály-diagram elemeinek pillanatnyilag létező példá- 
nyait, azok kapcsolatait szemléleti. 


Hűséges tanítvány -Hűséges tanítvány 








Id Objektumdiagram (A tanítás és a szervezés munká- 

ja természetszerűen a disznókra hárult, mert általáro- 
san elismerték, hogy ók a legokosabbak az állatok kö- 
Zött... Leghúségesebb tanítványuk a két igásló lett, Ban- 
di és Rózsi...") 


Az objektumokat két részből álló téglalapok reprezen- 
tálják, amelyek felső felében az objektum nevét és osz- 
tályát, alsó felében attribútumait tároljuk (aktuális érté- 
küket is feltüntetve). 


3. Komponens-diagram (component diagram) 
A komponensek egymáshoz való viszonyát fejezi ki. Ha 
egy komponens osztályok, interfészek és köztük lévő 
kapcsolatok együttese, ez az ábrázolásmód szoros kap- 
csolatban áll az osztály-diagrammal. 
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Forradalom. EXH 












Csak a disznók tudják.IDLL 








l 
l 
J 
1 


Állatizmus . XMIL 





Id Komponens-diagram (,Nem tudták, hogy az órnagy 
megjósolta Forradalomra mikor kerül sor, és jó okkal 
nem is gondolhattak arra, hogy az ő életükben bekövet- 
kezik, de világosan látták, hogy kötelességük felkészülni 
rá. ...a rendszernek az Állatizmus nevet adták.") 


A komponenseket a fent látható módon téglalapokkal 
jelöljük, bal oldalukon két kis ,fogacskával". A szagga- 
tott nyilak az mutatják, hogy mely komponens melyik- 
nek szolgáltat valamilyen információt, eljárást, stb. 


4. Telepítésilműködési diagram (deployment diagram) 
A futás közben igényelt erőforrásigényt, és a csomóponto- 
kon működő komponenseket ábrázolja. 






Hétparancsolat . XM; 





Ed Telepítési diagram (,, Ezt a Hétparancsolatot most fel 
fogják írni a talra, ezek változtathatatlan törvények 
lesznek, és az Állatfarm valamennyi állatának mind- 
örökké ezek szerint kell élnie."? 


Az erőforrásokat téglatestek ábrázolják, ezek közötti 
kapcsolatot, illetve a szoftverkomponensek , hovatarto- 
zását" szemlélteti a fenti ábra. 


5. Használati eset (use case) diagram 
A valós rendszer szereplőit, ezek kapcsolatát és tevékeny- 
ségeit mutatja be. A rendszer szervezése, viselkedésének 
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leírása és ellenőrzése szempontjából létfontosságú! 


TE 


Id Használati eset diagram (, Mennyit gürcöltek, izzad- 
tak, hogy begyűjtsék a szénát!/... De a disznók olyan 
okosak voltak, hogy minden nehézséget le tudtak gyóz- 
ni." 


Az UML diagramok másik csoportja, a dinamikus (más né- 
ven viselkedés-) diagramok az objektumok egymásra hatá- 
sát, kommunikációját, üzenetváltásait mutatják be. Négy 
típus sorolható ide: 
1. Szekvenciadiagram (seguence diagram) 
Az üzenetek küldésének és fogadásának időrendi sor- 
rendjét határozza meg, a használati esetekből kiindulva. 









Termés betakarítva 





1 





Termés raktáron 





l 
Elosztás 1 
Maradék Elosztás . ! 


Id Szekvenciadiagram (Az állatok ebben az évben úgy 
dolgoztak, mint a rabszolgák. ") 


Itt az üzenetváltás szereplőit nagy téglalapokkal jelöljük 
az ábra tetején. Az idő múlását a függőleges tengely 
szemlélteti, a cselekvéseket a szaggatott vonalú tenge- 
lyeken lévő hosszú téglalapok (ezek hossza a cselekvés 
időtartamával arányos). Az üzenetek a küldőtől a foga- 
dóig húzott nyíllal szerepelnek az ábrán. 


2. Együttműködési diagram (collaboration diagram) 
Az üzeneteket váltó objektumok kapcsolatát, és az üze- 


netváltás struktúráját ábrázolja. A szekvenciadiagramból 
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Sz 


egyszerű algoritmus alapján megkapható. 


A Elosztás 


5. Maradék elosZtás 4 


Dolgozni köriTermés raktáron 


TI 


Termés ED —g 


Együttműködési diagram a szekvenciadiagram alap- 


ján 


Az üzenetküldőket és -fogadókat itt egyszerű ellipszisek 
jelképezik, az üzenetek itt is a fentihez hasonló nyilak, raj- 
tuk az üzenet küldésének relatív időpontja (az üzenet sor- 
száma) és az üzenet neve. 


3. Állapot- vagy állapotátmeneti diagram (state-chart) 

A diagram csomópontjai állapotok, az irányított élek az ál- 
lapotok közötti átmeneteket reprezentálják. Rendkívül 
fontos az eseményorientált viselkedés vizsgálatánál. 





Parlagon 





EJ Állapotátmenet-diagram c Ez a munka szigorúan ön- 
kéntes volt, de aki kihúzta magát belóle, annak felére 
csökkentették a fejadagját.") 
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4. Aktivitás- vagy tevékenység-diagram (activity diagram) 
Speciális állapotdiagram, amely a végrehajtandó tevé- 
kenységek folyamatát mutatja. Jelentősége az objektumok 


vezérlési folyamatainak tervezésénél a legnagyobb. 























Olvasásra Javasol 









Megszerez 


Itt A Könyv 


Tetszik (Könyv) 





Aktivitás-diagram 


Amint ezekből az egyszerű példákból is látszik, az UML 
rendkívül sokoldalú modellezőnyelv. Remélem, sikerült 
mindenkit meggyőznöm arról, hogy a valós (vagy valósnak 
vélt) folyamatok több oldalról, több szempontból történő 
vizsgálata mennyire fontos. 

Sokoldalúsága mellett egyszerűsége az UML-t alkalmassá 
teszi arra is, hogy mindennapi munkánkban alkalmazzuk, 
nem kell megijedni az első ránézésre kacifántosnak tűnő 
ábráktól! Az UML óriási előnye, hogy a jelölésre koncent- 
rál, nem a konkrét tervezési módszerekre vagy megvalósí- 
tásokra, így bármit le lehet írni vele. Egy UML-lel megter- 
vezett rendszer pedig megvalósítható C-- ---ban, Javaban, 
Cst-ban, VB.NET-ben... 

A következő hónapokban részletesen is bemutatok né- 
hány hasznos , fogást", , trükköt", amelyet a modellalkotás 
során érdemes alkalmazni, és hamarosan már minden 
Tech.Net olvasó jártas lesz ebben a , misztikus" világban. 


Molnár Ágnes 
agnes.molnarOt-systems.com 


zereplő URL-ek: 
[1] http://wwweb.org/smo/bmc/ 
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Office XP Resource Kit 


Akik kicsit jobban belemélyedtek az Office lelkivilágába, azok már 
jól ismerik az Office Resource Kit eszközök nyújtotta lehetőségeket. 
Most egy újabb verzióját tölthetjük le ennek a csomagnak. 


A megszokott eszközök között újdonságokat is találhatunk, 
azonban a már ismert varázslók is nagyon jó szolgálatot tehet- 
nek. Nézzünk hát néhányat 


Answer Wizard Builder 

Aki használta már az Office súgóját, az biztos használta az Answer 
Wizardot is. Hányszor volt olyan, hogy hiába kerestünk rá egy-egy 
kulcsszóra mégsem találtuk meg a megfelelő bejegyzést? Ennek az 
is oka lehetett, hogy az adott információ nem szerepelt a súgóban. 
Az Answer Wizard Builderrel ezen segíthetünk. Ha van olyan 
speciális információ, melyet szeretnénk a súgóban szerepeltetni 
(legyen az egy nyomtató beállítására vonatkozó adat, vagy 
speciális, az adott környezetben használható sablon vagy makró 
hásználata), akkor azt az Answer Wizard Builder segítségével 
beépíthetjük súgónkba. 


System Management Server (SMS) package definiton files (PDFs) 
A javított PDF fájlok lehetővé teszik, hogy SMS 2.0 segítségével 
távolról telepíthessünk Office XP-t. Két PDF fájlt tartalmaz ez az 
update. Az egyik az OFF2002.SMS, amely a teljes Office XP-t 
magába foglalja, a másik pedig az LPK2002.SMS, mely az Office 
XP Multilingual User Interface Packs-t tartalmazza. 


Custom Installation Wizard 
Ez az eszköz az egyik leghasznosabb varázsló. A Custom 
Installation Wizard segítségével testreszabhatjuk az Office XP 
telepítését. Ehhez csupán a telepítéshez használt msi fájlra van 
szükségünk (a Office XP telepítő CD-jén megtaláljuk). A varázsló 
egy transzformációs fájlt (.mst) készít, melyben azok a változatások, 
beállítások kerülnek mentésre, amelyek az alapértelmezett 
telepítéstől különböznek. A telepítéskor pedig a Windows Installer 
ezeket a beállításokat fogja alakal mazni. Mivel a varázsló az ere- 
deti msi fájlt nem módosítja, ezért ahányféle mst fájlt készítünk, 
annyiféleképp telepíthetjük majd az Officet. Nézzünk néhány 
beállítási lehetőséget: 

" Kiválaszthatjuk, hogy melyek azok az alkalmazások, ame- 
lyeknek előző verzióját el szeretnénk távolítani. 

" Megadhatjuk, melyek azok a komponenssek, amelyeket 
telepíteni szeretnénk, és ez a telepítés azonnal vagy csak első 
használat esetén történjen meg, illetve az adott alkalmazást az 
adott gépről vagy hálózatról szeretnénk-e futtatni. 

" Létező Office Profilet (.ops fájl) adhatunk az mst fájlhoz, így a 
telepítés után már egy testreszabott profilt használhatunk. 

", Beállíthatunk olyan fájlokat, melyeket a telepítés után 
szeretnénk akár törölni, akár elhelyezni az adott gépen. Például 
elhelyezhetjük a vállalat fejléces papírját tartalamazó Word 
dokumentum sablonját minden felhazsnálónál. 

" Registry bejegyzéseket adhatunk meg, elindíthatjuk egyéb alka- 
Imazások telepítését és még lehetne folytatni a sort a beállítási 
lehetőségekről. 
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Az mst fájl mentése után egy ablakot kapunk, melyben található 
egy parancssori utasítás. Ezzel az utasítással futtathatjuk a varázs- 
lóval beállított egyéni telepítéseket. 


Office Profile Wizard 

A Profile Wizard segítségével elmenthetjük egyéni beállításainkat, 
mint például mely eszköztárakat használjuk, mi az alapértelmezett 
elérési útja a fájloknak. A varázslóval azt is beállíthatjuk, hogy a 
felhasználók ne változtathassák meg beállításaikat, de a megosz- 
tott sablonokat megnyithassák. 

A felhasználói profilokat OPS fájlokba menthetjük, valamint 
azokat vissza is állíthatjuk a varázsló segítségével. 


Removal Wizard 

Ezzel az eszközzel eltávolíthatjuk azokat az állományokat, 
melyeket szeretnénk, azt is megadhatjuk, melyek maradjanak. Ezt 
a varázslót kell akkor is használni, ha egy korábbi Office verzióról 
szeretnénk Office XPre upgrade-elni. A Removal Wizard a 
következő programokat ismeri fel és távolítja el: Microsoft Office 
4.x, Office 95, Office 97 és Office 2000, Multilanguage csomagok 
és egyedi Office alkalmazások. 


Setup INI Customization Wizard 

Ezzel az eszközzel egyéni telepítési beállításokat készíthetünk, illetve 
módosíthatunk. A varázsló automatikusan az ini fájl megfelelő 
részébe írja az általunk kért beállításokat. Valamint létrehoz egy 
parancssort is, mely tartalmazza a /settings kapcsolót és az általunk 
megadott ini fájlt. 


OPS File Viewer 

Az OPS File Viewer segítségével megnézhetjük azokat a módosítá- 
sokat, melyeket egy Office profil beállításakor (OPS fájl) 
eszközöltünk. Ez a nézőke azoknak a lehetséges változtatásoknak a 
listáját is megmutatja, amelyeket az Office Profile Wizardban beál- 
líthatunk egy felhasználónak OPS fájl segítségével. 

Az OPS File Viewer használatához ismernünk kell egy Profile 
Wizard által létrehozott ops fájl nevét és helyét. Ez az alkalmazás 
az megadott ops fájlt olvassa majd készít belőle egy szöveges 
állományt, melyet akár Notepad segítségével is elolvashatunk. 


Borsi Katalin 
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Orregér 


Azok, akik hosszú órákat töltenek a számítógép előtt, tudják mit jelent egy nem éppen 


kifogástalanul működő egér. A mikrokapcsolók — inkább előbb, mint utóbb - már csak 
eredménytelenül kattognak, a golyóra minden szösz ráragad, a görgőkre kiválóan tekere- 
dik fel a leghosszabb hajszál, és az egéralátét vagy a kábel éppúgy véget ér, mint a türelmünk. 


A műszaki élet persze már rég túllépett ezeknek a problémáknak 
a többségén: kapható drót nélküli, rádiós egér, golyó nélküli 
egér, trackball. Ezek sem enyhítik azonban a kar zsibbadását, a 
féloldalas testtartást és az ülőhely(zet) korlátozott megválasztását. 


Jedi trükk 

Amikor nemrég a fenti problémákkal küszködtem, arra gon- 
doltam, de jó lenne, ha az egérkurzor oda menne, ahová gon- 
dolom, valahogy így: le, elég, kicsit jobbra, kattints, gyorsme- 
nüt, növeld meg a betűméretet stb. Azt hittem szép álom, míg 
a [1] cikk fel nem világosított az ellenkezőjéről. Röviden össze- 
foglalva az történt, hogy egy majom agyának több, motoros 
funkciót végző idegsejtjéhez rendkívül vékony elektródákat 
vezettek, és megfigyelték, mi történik, ha a majom egy bizo- 
nyos betanult cselekvéssorozatot hajt végre. A szemfüles kuta- 
tóknak sikerült a neuronok akciópotenciáljának függvényében 
egy robotkart a majom karjával szinkronban mozgatni. Par- 
don, a majom tudja azt a bizonyos kart mozgatni a kutatók se- 
gítségével. Sajnos ez a megoldás sem nélkülözi a vezetéket, de 
a kutatók szerint lehetséges olyan agyi implantátum készítése, 
amely rádiójelekkel juttatja el a szükséges információt a célbe- 
rendezéshez, például egy egérhez. A pillanatnyilag távolinak 
tűnő jövő világából térjünk most vissza a jelenbe, és nézzük 
meg, mi történik e téren az egeret felfedező nagy testvér mű- 
helyében. 


Menjünk inkább az orrunk után 

Így gondolja Kentaro Toyama, a Microsoft kutatója, aki olyan 
egyszerű és olcsó rendszer megalkotásán fáradozik, amely az 
orr irányának megfelelően változtatja a kurzor helyét [2]. A 
monitorra helyezett webkamera képéből megállapítható az 
arc helye és síkja, majd az orrból erre állított merőleges és a 
képernyősík metszéspontjából máris megkapjuk az egér he- 
lyét. Ez amilyen egyszerűnek hangzik, pontosan olyan bonyo- 
lult, különös tekintettel az arc paramétereinek meghatározá- 
sára. Ügyelni kell a különféle bőrszínekre, a bajszosokra, a 
szakállasokra, a fényviszonyok megváltozására, a kamera lá- 
tóterében lévő más személyekre, és arra is, ha elfordulok né- 
hány másodpercre beszélgetni valakivel. Bármi is történjék, 
az egérnek ott kell cincogni az orrom előtt, ha visszanézek a 
képernyőre. 

Toyama az IFA (Incremental Focus of Attention) architektúra 
arckövetésre átalakított változatát használja a feladat megvaló- 
sítására. Az IFA több követőalgoritmus összegyúrásával az arc 
robusztus, valós idejű követését teszi lehetővé. Toyama jelen- 
legi megoldásában egy véges állapotú gép hat réteg működé- 
sét vezérli. Ahogy az első rétegtől a hatodik felé haladunk, 
egyre pontosabban tudjuk, hol áll a fejünk. Ekkor keresésből 
követésbe csapunk át, egészen addig, amíg a zavaró körülmé- 
nyek miatt nem kell a 3. rétegnél lejjebb ereszkedni. Vegyük 
sorra, mi történik a keresés hat fázisában, így képet kapunk 
mindegyik réteg funkciójáról: 

Az 1. réteg a pixeleket osztályozza a színüket jellemző RGB 
értékük alapján, pontosabban aszerint, hogy az R/G és az R/B 


hányadosok egy meghatározott tartományba esnek-e. A 2. ré- 
teg az intenzitás változását vizsgálja spirális pályákon, és ennek 
megfelelően azokra a képterületekre szűkíti a keresést, ame- 
lyek megfelelnek a bőrszínnek, és emellett a mozgásuk is je- 
lentős. Ez a két réteg pixelek halmazát állítja elő, és csak a ke- 
resésben vesznek részt, a követésben nem. 

A 3. réteg addig terjeszkedik a középpontból 16 különböző 
sugárirányban, amíg bőrszínt talál. Ekkor már hozzávetőleg 
ismerjük az arc helyét a képernyővel párhuzamos síkban. A 
4. réteg ugyanezt teszi, de a helyen túl az irány közelítő szá- 
mítását is elvégzi. Az 5. réteg Greg Hager munkáját dicséri 
azzal, hogy előre megadott sablonokat próbál iteratívan a 
webkamera képeire illeszteni a távolságok négyzetes össze- 
gének segítségével. Végül a 6. réteg az arc öt karakteres 
pontját figyeli: a szemeket és az orrlyukakat az intenzitás kis 
terültre szűkített vizsgálatával és a szájat a kontúr követésé- 
vel. Az öt pontot a legkisebb négyzetek elvén összevetjük az 
előre megadott referenciapontokkal, ami néhány egyszerű 
mátrixműveleten keresztül eljuttat bennünket a kívánt ered- 
ményhez. 


Alkalmassági vizsga 

Toyamanak egy ma már a legjobb esetben is csak átlagosnak 
mondható számítógépen legfeljebb egy-két tizedmásodperc 
alatt sikerül az egeret a helyére raknia a legnehezebb helyze- 
tekben, az átlagos felhasználó pedig képes 1 cm x 1 cm-es ab- 
lakba pozicionálni a kurzort. A zajszűrés tovább javítható és 
így a kurzor helyzetét még pontosabban lehetne beállítani, 
azonban a válaszidő ekkor már észrevehetően megnőne. 
Mindez biztosíték arra, hogy némi finomítás után az orregér- 
nek jó hasznát vehetik a mozgáskorlátozottak, a játékok és 
egyéb szórakoztató-programok szerelmesei vagy bárki más a 
mindennapi munkája során, néhány speciális, az egér rendkí- 
vül finom mozgását megkövetelő esettől eltekintve. 

Kimaradt a kattintás, ez azonban viszonylag könnyen megold- 
ható, például pislantással, szájmozgással vagy hangfelismerés- 
sel. Aggasztóbb az, hogy a szabadság kiterjesztése egyes terü- 
leteken korlátozásokkal jár másokon: probléma lehet az irá- 
nyítás átadása a mellettünk ülőnek és a felhasználótól megkí- 
vánt fegyelem is (elsősorban nem a reggeli borotválkozásra, 
hanem a fej megfelelő szögben tartására gondolok). 

Az orregérrel mindenesetre már kényelmesen hátradőlhet- 
nénk a fotelben, azonban sokat kell még kattintani, amíg a 
boltokban is kapható lesz. 


Zaccordfw.hu 


A cikkben szereplő URL-ek: 





(1. http:/Avww.sciam.com/article.cím?chanID—sa006 gaarticlelD—00065FI 


DAEA-1D80-90FB809EC5880000 
[21 http://research.microsoft.com/toyama/research.htm 
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ACADEMIA , BZNETLOCK 


ésa Az Első Hitelesítés Szolgáltató 
közös szervezésében 


Szerezzen átfogó tudást az elektronikus aláírás és titkosítás vállalati szintű 


alkalmazásában 





Technikai blokk: 
. Mi az a kriptográfia? 
ü Hogyan tudunk nyílt hálózaton kommunikálni úgy, hogy azonosítani tudjuk kommunikációs partnerünket? 
. Meg tudunk bizonyosodni üzeneteink sértetlenségéről? 
. Hogyan működik a titkosítás? Mi a kulcspár, a tanúsítvány, mi a szerepe az intelligens kulcstároló eszközöknek? 


További témakörök: 
. szimmetrikus algoritmusok, nyílt kulcsú RSA, hash, a X.509 tanúsítványok szerepe és használata, 


. hitelesítésszolgáltató, a hierarchia felépítése, 
. kulcstároló eszközök: intelligens kártya és USB Token, 
. bejelentkezés tanúsítvánnyal (Single Sign On), SSL, S/MIME, HTTPS, 
. virtuális magánhálózatok. 
Jogi blokk: 


. az elektronikus aláírási törvény célja, következményei, a végrehajtási rendeletek. 
. Jogkövetkezmények, és a szükséges feltételek megléte. 


Ajándék! 


2 ] ht ga ő 4 NetLock C-osztályú 
j Ó B tanusítván 
jé VAGY Van h c y 


USB-token Smart Card olvasó és kártya 











Hallgatóink a tanfolyamon használt kriptográfiai eszközöket a tanfolyam után megtarthatják, és - a mellékelt 
NetLock tanúsítványokkal - hiteles elektronikus aláírást és nyílt kulcsú titkosítást használhatnak! 





Hozza el a főnöké ési határidő: 2002. november 29. 
Ha cégüktől két fő jelentkezik a PKI-workshopra, mindketten ingyen részt vehetnek Mikulás-konferenciánkon! 


(Mikulás-konferenciánkról további információk az első borító hirdetésében vagy a http://www.netacademia.net/mikulas címen!) 


























A tanfolyam időpontjai inaSi, Bővebb információ és jelentkezés 3 Ár [Ft] eze 
2002. december 10. 2 http://www.netacademia.net/workshop/PKI I 140,000 s. fŐ 
2003. január 14. 2 http://www.netacademia.net/workshop/PKI ! 140,000 ése TŐ 





Részletekről érdeklődjön a 06/1/472-1214-es telefonszámon vagy az info.,y;onetacademia.net e-mail címen! 


A tanfolyam helyszíne: Budapest 1062, Andrássy út 62. 


Microsoft ; 
- Magy a tankból legyen 


Cégek, nagyvállalatok részére, a csoportmunkát teljes 


A projektirányítás számos szervezet sikerében és bu- 

kásában játszik fontos szerepet. Egy hatékony mértékben támogató Project 2002 Professional 
tervezési eszköz birtokában csökkenthetők a kínálja a Microsoft, mely segítségével és a köz- 
költségek és javítható a termelékenység, ami ponti nyilvántartást és kiszolgálást biztosító 
nyereségnövekedést eredményez. A Microsoft Project 2002 Server termékkel együttműködve 
Project 2002 Standard minden eddiginél egy- teljeskörű nagyvállalati, projektirányítási, terve- — . 
szerűbbé teszi az ütemezések és erőforrások zési és döntéshozási feladatok végezhetők el, és 
kezelését, a projekt állapotának közlését és a annak adatai bármikor, bárhonnan hozzáférhe- 

tőek, publikálhatóak. 


projekt adatainak kimutatását. 


Ismerje meg N .  tanfolyamainkon! 


fözelebbtő 


Microsoft Project 2002 felhasználói kurzusok 


Az érdeklődők kétnapos, intenzív tanfolyamok keretében ismerkedhetnek meg a Microsoft Project 2002-es verzióinak használatával. 


Rugalmas időbeosztás 


Megpróbáltuk figyelembe venni, hogy a cégek dolgozóikat nem tudják nélkülözni hosszabb időre, ezért a tanfolyamokat intenzív, egész 
napos formában hirdettük meg, délelőtt 9.00 és 16.00 óra között. A tanfolyamok díja az oktatás és a tananyagok mellett az étkezést is 


tartalmazza a kurzus napjaira. 


Project 2002 Professional és Server - testreszabott oktatások 

Oktatóközpontunkon kívül, a megrendelő telephelyén, kihelyezett formában (vidéken is) is vállaljuk az adott cégprojektekhez kapcso- 
lódva tanfolyamok vagy konzultációk megtartását és lebonyolítását, különös tekintettel az összetett, Project 2002 Professional és 
Project 2002 Server használatával és bevezetésével kapcsolatos témákban. Ezt követően igény esetén további utólagos támogatást 


és szaktanácsadást is nyújtunk. 


Tervezze üzleti folyamatait Microsoft Project 2002-vel! 
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Kedves Olvasónk! 


A tech.net magazin több mint két éve látja el olvasóit hónapról hónapra információkkal, taná- 
csokkal. Szerkesztői és készítői most szeretnék megismerni az Ön véleményét is a kiadványról. 
Ahhoz, hogy januártól még inkább az igényeinek megfelelő lapot tarthasson kezében, kérjük, 


válaszoljon az alábbi kérdésekre. A kitöltött kérdőívet 2002. december 10-ig postán vagy faxon 
visszaküldők között Microsoft Kormányt és játékszoftvereket sorsolunk ki. 


Címünk: Max 8 Future Kft. 1519. Bp. Pf. 427. 
Fax: 06 1 372 8466 


A kérdőív interneten is kitölthető és visszaküldhető: http://microsoft.com/hun/technet/Survey.asp 
1. Mióta olvasója a tech.net magazinnak? 


a. 2000-től b. 2001-től c. 2002-től 


2. Hogyan jut a magazinhoz? 


a. előfizetem b. rendezvényeken 

c. tiszteletpéldányt kapok Ör eGY 6 a arnvssé sss tstátéátáéses 
3. Milyen gyakorisággal olvassa a magazint? 

a. minden számot elolvasok b. időnként, amikor ráérek 

c. elteszem, és konkrét problémánál d éGYÉD sdslsssgéteéstássításás 


olvasom el az arról szóló cikket 


4. Miaz; amit kedvel a magazinban seepressáménéseges nee kád azé elés e SÁNAK EN TÉN eseté ednssó 


Folytatász 5 


7. A magazinnal kapcsolatos egyéb észrevételek: ..................... ll lllslslsisssesssses 


8. Ismeri a Microsoft TechNet eseménysorozatát? 


a. igen b. nem 


9. Ha igen, milyen gyakran látogatja? 


a. félévente 1-2 alkalommal b. félévente 3-4 alkalommal 

c. félévente 5-6 alkalommal d. még nem vettem részt egyen sem 
10. Olvassa-e a tech.net Klub levelező listáit, ha igen mely listákat? .......................... 
Vt ENLLENŐBS eget kettkáz kezéért e TÉK ÁT ANT ÁT EENK ÉTÉ TÉK ANÁA KNLS ÉKE Á ES ÁTÉKÁSE RÉ LK KÉS BEAT ÉNSTT 
Foglalkozása ségtsasápemezmetáésá részér ágát tás ez ES ÁS SÉTA ka E E aÜ Ses td tátátták 
BEGSZTÁSAS srétütétéjás értsen étérsés etes be e étS ter ál Ő Stb BT TÉETELŐ STEAK TÉS ÁE ELSTÉSÉS ÉNEK GÉÉ SEL TSTÉLSSTE TE S ÉTELE ÉTÉTE 
ÉÍMEL dsnsznüzs atát sétát tüz Ko kn e tk ÜL TKÜL ÉKE RE NA BEKANSS E BASA Sa Set ska sléés 
EGÁL ETKNÉSS zsét áststásé tést és ét ÉSE KÉLSÉ NETÁN VÉLTE Ál AL ÚÁAS A AELHÁSÉS ÉÁ ÉTTÁÁÍNTS ETTEK SL ÍVE ANT OO GYE NEG 
TElelÖKSZÁMAÁ S eenéstánéűséétemékáete teng katam át SK BEDSÉKKÜK SÉGEK ETEL ÓS SEL ETEK HEBGEÉ 


KÖSZÖNJÜK, HOGY VÁLASZOLT KÉRDÉSEINKRE! 


